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^Thls  report  describes  a  model  of  team  organization  and  performance,  and  a  method 
for  describing  the  structures  and  behavior  of  teams.  Both  the  model  and  descrip 
tion  method  were  developed  and  validated  through  the  field  observation  of  Army 
teams  performing  selected  team  missions.  The  model  is  a  set  of  concepts  which 
are  used  to  describe  the  formal  and  actual  (mission)  structure  of  teams  and 
the  behavior  of  teams  and  team  members.  The  description  method  essentially 
provides  a. structured  means  of  identifying,  gathering,  and  verifying  the  data 
required  to  describe  teams  and  team  missions,  using  the  concepts  of  the  model.  — 


MODE!.  OK  TEAM  ORGANIZATION  AND  BEHAVIOR  AND  TEAM 
DESCRIPTION  METHOD 


EXECUTIVE  SUMMARY 


Requirement 

The  objectives  of  this  first  year  of  a  three-year  research  effort 
were  to  develop  two  research  products:  Cl)  a  model  of  the  organisation 
and  performance  of  any  military  team  performing  any  team  mission;  and 
(2)  a  structured,  procedural  method  for  describing  the  structure, 
organization,  and  performance  of  teams,  based  on  the  model.  This 
report  describes  both  the  model  and  description  method,  including 
discussions  of  the  way  in  which  these  two  products  were  developed  and 
validated. 


Procedure 

The  investigators  initially  recognized  that  no  existing  model  of 
team  or  small  group  behavior  was  sufficiently  general  and  comprehensive 
to  be  used  as  a  foundation  for  the  model  to  be  developed.  Under  this 
basic  condition,  a  "primitive"  model  of  the  behavioral  eleannts  of  team 
performance  was  created  at  the  outset  of  the  effort.  This  primitive 
model  evolved  into  the  present  model  in  two  ways.  First,  the  existing 
literature  on  team  and  small  group  behavior  was  reviewed  to  identify 
useful  concepts  which  could  contribute  to  a  general  model  of  team 
organization  and  behavior.  Potentially  useful  concepts  were 
synthesized  and  incorporated  into  the  primitive  model.  Most  major 
features  of  the  model  were  developed  through  the  observation  of  a 
variety  of  Army  teams  performing  many  different  team  missions.  Four 
"waves"  of  observation  were  conducted  during  model  developswnt  at 
different  FORSCOM  posts.  At  each  post,  several  observers  watched  teams 
performing  missions  and  discussed  the  missions  with  seabers  of  the 
teams  that  were  observed.  Each  of  the  teams,  and  missions,  performed 
was  described  in  terms  of  the  concepts  of  the  model  as  it  existed  at 
the  time  of  observation.  When  new  concepts  or  features  wars  needed  to 
adequately  describe  teams  or  missions,  such  concepts  were  developed  and 
refined  by  the  project  team  between  observation  sessions.  Eventually, 
the  model  and  its  components  became  complete  enough  to  accurately 
describe  alt  the  organizat ional  and  behavioral  characteristics  of  all 
teams  and  missions  observed  during  model  development.  The  completeness 
and  generality  of  the  model  were  verified  by  observing  both  team  types 
and  missions  that  had  been  previously  observed  and  those  that  had  not. 
The  concepts  and  constructs  of  the  model  were  found  to  be  adequate  for 
describing  the  organization  and  the  mission  performance  of  the  teams 
observed  during  verification. 

The  team  description  method  was  developed  in  parallel  with  the 
model ,  as  the  model  evolved.  When  new  concepts  were  added  to  the 
model,  ways  to  describe  the  team  organization  or  performance 
characteristics  associated  with  the  hew  model  concept  were  explored. 


The  new  or  revised  description  techniques  were  evaluated  during  field 
observation,  and  the  ability  of  the  techniques  to  yield  accurate 
information  in  the  desired  form  was  assessed  after  trial  use. 

Description  techniques  which  were  found  to  be  overly  cumbersome  or 
difficult  to  use  or  which  did  not  resutt  in  the  quality  of  data  desired 
were  revised,  or  discarded  and  replaced  by  alternative  procedures.  The 
utility  and  comprehensiveness  of. the  description  method  was  validated 
by  applying  the  description  techniques  to  team  types  not  observed 
during  creation  of  the  model  and  description  method.  Several 
shortfalls  in  the  original  description  method  were  discovered  during 
validation,  and  modifications  to  the  description  method  were  made  to 
overcome  the  problems  generated  by  those  shortfalls.  These  changes  are 
ref  1  ected  in  the  description  method  as  it  is  presented  io  the  body  of 
this  report. 


The  model  consists  of  two  parts.  The  first  part  consists  of  a  set 
of  concepts  and  terms  for  describing  the  structure  and  organization  of 
teams  both  in  the  abstract — i.e.,  out  of  context  of  particular  missions 
(nominal  team  structure),  and  in  the  context  of  particular  missions 
that  are  performed  by  teams  (actual  team  structure)*  For  each  type  of 
team  structure,  a  number  of  terms  and  descriptive  diswnaions  are 
defined.  The  second  part  of  the  mode  1  deals  with  concepts,  terms,  and 
approaches  for  describing  the  behavior  of  teams  as  the  teams  perform 
missions.  Only  two  basic  components  are  needed  to  describe  the 
behavior  of  a  team  under  this  model:  description  of  the  individual 
tasks  performed  by  team  members  and  the  dependencies  among  team  swmbers 
(dependencies  are  events  in  a  mission  'where  one  team  member  receives 
input  from  one  or  store  other  team  stembers  which  permits  the  receiving 
member  to  initiate,  continue,  or  complete  his  individual  tasks). 

The  description  method  based  on  the  model  contains  four  steps. 

Each  step  has  associated  with  it  a  set  of  data  requirements  and 
procedures  for  data  gathering  and  presenter  ion.  The  first  step  is 
concerned  with  identifying  the  teams  and  team  types  to  be  described, 
and  selecting  teams  for  description.  Step  two  deals  with  preparing 
detailed  descriptions  of  the  structural  and  organisational 
characteristics  of  the  teams  selected  in  step  one.  The  third  step 
concerns  selecting  missions  to  be  described  for  the  teaie  types  selected 
in  step  one.  The  fourth  and  final  step  deals  with  describing  the 
behavior,  structure,  ami  performance  of  teams  as  they  perform  the 
missions  selected  in  step  three.  Detailed  procedures  for  recording, 
analyzing,  and  describing  the  performance  of  teams  are  provided  in 
discussion  of  each  step.  Standardized  documentation  forms  to  record 
data,  observations,  and  decisions  aggregated  during  preparation  of  team 
descriptions  are  included,  and  procedures  for  date  recording  are 
provided. 


The  mode  1  has  already  been  used  in  the  development  of  the  method 
for  describing  the  structure,  organization,  and  performance  of  teams  in 
this  first  year’s  effort.  .  Hie  model  and  the  description  method  will  be 
extensively  refined  in  the  following  years  of  the  effort,  and  used  to 
provide  the  foundation  for  several  developments:  creating  methods  for 
evaluating  the  performance  of  teams;  developing  a  method  for 
identifying  team  training  requirements  for  various  types  of  teams;  and 
evolving  guidelines  for  selecting  techniques  for  team  training. 
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MODEL  OK  TEAM  ORGANIZATION  AND  3EHAVIOR 
INTRODUCTION 

This  report  describes  a  model  of  team  structure  and  behavior  based 
on  the  observation  and  study  of  real-world  'Army)  teams  and  team 
missions.  Unlike  many  previous  team  performance/team  behavior  models, 
the  model  described  here  was  based  on  the  assumption  that  it  would 
ultimately  be  used  to  support  assessment  of  team  performance  in  the 
real  world  and  the  development  of  team  training  programs.  This  is  not 
intended  as  a  criticism  of  previous  research  in  team  behavior,  but  as  a 
comment  on  the  utility  of  the  findings  of  team  research  to  date.  Moat 
studies  of  teams  and  team  performance  to  date  have  been  ba^ic  and 
exploratory:  attempts  to  describe  and  explain  the  differences  in 
performance  of  teams  from  that  of  individuals.  A  very  wide  variety  of 
group  entities  and  tasks  has  been  studied  under  th-»  general  rubric  of 
"team  research,"  and  many  valuable  observations  and  speculations  have 
resulted  from  this  work.  Many  attempts  have  been  made  to  model  both 
the  performance  of  teams  and  the  effects  of  various  characteristics  of 
team  organization  and  structure  on  team  performance  phenomena. 

The  diversity  and  variety  of  group  entities  and  tasks  that  have 
been  studied  previously  has  led  to  the  development  of  nearly  as  many 
exploratory  and  descriptive  concepts  about  team  performance  as  there 
have  been  researchers  in  the  fieid.  Unfortunately ,  the  very  variety  of 
situations  studied  and  investigative  orientations  has  resulted  in  a 
situation  where  the  findings  and  concepts  of  team  research  cannot  be 
integrated  in  a  meaningful ,  theoretical  way.  There  is  no  predictive 
theory  of  team  performance  in  existence,  despite  the  large  body  of  data 
on  team  performance  and  the  many  descriptive  models  that  have  been 
developed.  The  wide  Variety  of  definitions  of  tdtat  kinds  of  entities 
are  to  be  called  teams  (and  the  frequent  failures  to  define  the 
boundaries  of  teams  as  opposed  to  other  entities),  the  diversity  of 
team  tasks  or  missions  studied,  and  the  frequently  contradictory 
results  of  studies  make  a  general  theoretical  statement  impossible. 

One  difficulty  in  arriving  at  any  theoretical  picture  of  team#  in 
general  is  the  lack  of  a  set  of  concepts  sufficiently  general  to 
describe  all  possible  teams  and  team  missions/tasks  in  a  consistent  and 
comparable  way.  Such  a  sot  of  concepts  could  he  thought  of  as  a 
"language  of  discourse"  for  thinking  about  and  studying  teams  and  team 
behavior.  Such  a  sot  of  concepts,  if  widely  accepted,  could  be  usud  to 
describe  the  character i at ics  of  the  structure,  organization,  and 
behavior  of  any  team  in  ways  that  would  make  the  comparison  of  teams 
and  tea*  behaviors  possible.  With ,a  large  enough  act  of 
team-characterist ic  descriptions  based  on  the  name  sat  of  concepts  and 
description  rules,  the  relationships  between  team  structure, 
missions,  and  performance  can  be  identified.  Relationships,  between 
these  characterist ics  of  teams  can  eventually  lead  to  general  or 


specific  predictions  or  hypotheses  about  the  ways  in  which  various 
characteristics  of  teams,  team  tasks,  and  the  environment  in  tdiich 
teams  perform  influence  the  behavior  and  performance  of  teams.  A 
sufficiently  general  set  of  validated  hypotheses  will  lead  to  the 
much-desired  "theory  of  team  performance." 

The  model  described  here  represents  the  first  step  toward  a 
general  theoretical  statement  about  team  behavior  and  performance. 

This  model  is  a  consistent  and  understandable  set  of  concepts  fur 
describing  the  structure,  organization,  and  behavior  of  teams,  based  on 
the  observation  and  study  of  a  variety  of  real-world  teams  performing 
real-world  missions.  Since  time  and  resources  for  model  development 
were  limited,  only  a  representative  variety  of  Army  teams  could  be 
observed  to  develop  model  concepts.  Thus,  this  model  is  viewed  as 
probably  incomplete  from  one  or  more  viewpoints.  The  authors  believe, 
however,  that  this  model  represents  a  good  first  approxipetion  to  a 
consistent  method  of  thinking  about  and  studying  team  behavior  and 
performance,  which  can  he  easily  expanded  and  refineo  to  represent  all 
the  important  or  necessary  characteristics  of  teams  and  the  performance 
of  teams. 

The  remainder  of  this  section  is  divided  into  three  chapters. 
First,  a  brief  discussion  of  the  way  in  which  the  model  wa*  developed 
is  offered.  The  limitations  of  the  model  are  also  discussed  in  a 
general  way.  Next,  the  concepts  of  the  model  are  presented  in  detail. 
Finally,  a  brief  discussion  of  planned  future  developments  to  the  model 
and  attempts  at  application  of  the  model  is  presented. 
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MODFL  DKVF.LOPMF.NT  AND  LIMITATIONS 


Development  of  the  team  structure  and  behavior  model  was  performed 
in  cwo  stages.  The  first  stage  began  with  a  detailed  review  of  the 
available  literature  on  team  and  small  group  behavior.  The  emphasis  of 
this  review  was  to  discover  key  concepts  relating  to  the  structure  and 
behavior  of  teams  which  could  be  synthesized  into  a  set  of 
understandable  and  general  methods  of  describing  teams  and  their 
behavior.  Stress  was  placed  on  identifying  integrating  concepts  of 
team  structure  and  performance,  definitions  of  teams  (boundary 
conditions  that  discriminate  teams  from  other'  group  entities),  and 
models  of  team  behavior. 

When  data  or  concepts  relevant  to  any  of  these  key  areas'  were 
discovered,  the  data  were  integrated  into  a  primitive  model  of  team 
behavior.  This  primitive  model  was  only  a  conceptual  framework  into 
which  useful  concepts  could  be  integrated,  rather  than  an  attempt  to 
pre-specify  a  set  of  concepts.  The  primitive  model  stressed  two  key 
elements  of  team  behavior: 

.  the  performance  of  individuals  in  team  context  as  the  individual 
performance  contributes  to  the  performance  of  the  team  as  a 
whole;  and 

.  the  dependencies  among  team  members  required  to  accomplish  team 
tasks  or  missions. 

The  primitive  model  did  not  contain  specific  concepts  related  to  these 
two  elements,  nor  any  concepts  related  to  team  structure  or 
organization.  It  was  felt  that  maximum  flexibility  would  result  if 
existing  concepts  were  reviewed  and  synthesized,  rattier  than  providing 
limiting  categories  into  which  research  findings  and  concepts  would  be 
sorted. 

Based  on  the  literature  review,  the  primitive  model  was  expanded 
into  a  set  of  team  structural  and  behavioral  concepts  which  were  felt 
to  incorporate  the  useful  findings  and  speculations  of  pc  work 
without  being  limited  by  the  constraints  inherent  in  the  b.  j  of  data 
evolved  to  date.  A  number  of  extremely  useful  and  critical  features 
were  added  to  the  primitive  model  as  a  result  of  the  review  of  existing 
literature.  For  example,  the  original  primitive  model  had  no  way  to 
characterize  the  structure  and  organization  of  teams  in  a  consistent 
way.  A  number  of  team  structure  aru  organization  concepts  found  in  the 
literature  were  considered  together  and  the  best  features  of  each  of 
these  were  synthesized  to  form  a  set  of  structural  concepts  and  terms 
which  were  felt  to  have  face  validity  for  description  of  any  type  of 
team.  These  terms  and  concepts  were  added  to  the  primitive  model. 


Table  1 


Team  Types,  Sites,  and  Missions  Observed 
During  Model  Development  and  Validation 


Team  Type 

4.2-in  (107  mm) 
Mortar  Squad 


Improved  Tow  Vehicle 
(ITV)  crew 

Infantry  Squad 


81  mm  Mortar  Squad 


81-mm  Fire  Direction 
Center  (FDC) 


TOW  Crew 


Combat  Engineer  Squad 


Site  Missions  Observed 

Ft.  Benning,  GA  Registration  and  adjust 

fire,  repeat  fire  mission, 

split  mission  (two 
sections) 

Ft.  Benning,  GA  Dismount  TOW,  mount  TOW, 

simulated  fire  missions, 
reload,  immediate  action 

Ft.  Riley,  KS  Prepare  tactical  fighting 

positions,  conduct 
reconnaisance  patrol, 
daylight  defense, 
provide  security  for 
combat  engineers 

Ft.  Riley,  KS  Registration  and  adjust 

fire,  repeat  fire 

missions,  traversing  fire, 
reduced  strength  fire 
missions  (1  and  2-man) 

Ft,  Riley,  KS  Call  for  fire  (initial), 

adjust  fire  missions, 
section  split  missions, 
reduced  strength  (2  men) 

Ft.  Riley,  KS  Dismount,  and  emplace  TOW, 

erect  camouflage  and 
improve  positions, 
simulated  fire  missions, 
disassemble  TOW  and 
remount  vehicle 

Ft.  Riley,  KS  Install  triple  standard 

concertina  obstacle, 
install  tactical 
minefield,  construct 
antitank  trench 
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Table  l  (concluded) 


Team  Types,  Sites,  and  Missions  Observed 
During  Model  Development  and  Validation 


Team  Type  Site  Missions  Observed 

Infantry  Squad  Ft.  Benning,  GA  Squad  tactical  training 

missions;  movement  to 
contact,  deliberate 
daylight  attack,  squad 
movement  techniques  drill, 
night  attack,  obstacle 
crossing,  body  search, 
military  operations  in 
urban  terrain  (MOUT) 


I  TV  Crew  Ft.  Benning,  GA  Operational  checkout, 

reload  and  immediate 
action,  crew  drill 
(mount/dismount  TOW), 
sisniiated  firing  and 
tracking 

Assault  Ribbon  Bridge  (ARB)  Ft.  Benning,  GA  Staging,  launch,  and 

Platoon  recovery c£  bridge 

sections  and  bridging 
boats,  construction  of 
5-bay  raft,  rafting, 
bridge  construction 


4.2-in  Mortar  Squad 
4.2-in  FDC 
Infantry  Squad 


Infantry  Squad,  Platoon 


105-mm  Artillery  FDC 


Ft.  Benning,  GA  Night  illumination  fifing 

Ft.  Benning,  GA  Night  illumination  firing 

Ft.  Bragg,  NC  Movement  to  contact, 

deliberate  attack,  hasty 
attack,  construction  and 
camouflage  of  defensive 
positions,  defend 
positions  against  attack 

VALIDATION  BELOW  - - 

Ft.  Campbell,  KY  Movement  to  contact,  hasty 

attack,  hasty  defense, 
raid,  deliberate  defense 

Ft,  Campbell,  KY  Initial  call  for  fire, 

adjust  fire,  split 
missions,  repeat  missions 


subjected  each  concept  and  construct  to  a  series  of  questions,  answered 
by  the  project  team  as  a  whole.  The  questions  used  were: 

.  Is  the  concept  clearly  defined  by  example  in  the  observations, 
and  can  the  concept  nr  construct  be  stated  and  easily  defined  in 
a  comprehensible  way? 

.  Does  the  concent  appear  to  be  consistent  and  generalizable 
across  team  types  and  missions?  Is  there  reason  to  believe  that 
the  concept  should  be  broken  down  into  sub-concepts  that  more 
clearly  and  explicitly  reflect  what  has  been  observed?  What 
breakdowns  appear  reasonable? 

.  Does  the  concept  or  construct  add  materially  to  our  ability  to 
describe  the  structure  or  behavior  of  teams?  Does  the  concept 
"fill  holes"  in  characterizing  team  structure  and  behavior,  or 
does  it  merely  duplicate  other  concepts? 

.  Is  the  concept  or  construct  meaningful?  Does  it  represent  a 
genuine  characteristic  or  attribute  of  teams  and  their 
performance,  or  is  it  merely  an  observational  artifact? 

General,  but  binding,  criteria  for  the  model  were  selected  and 
adopted  at  the  outset  of  the  effort,  and  are  reflected  in  the  questions 
used  to  evaluate  candidate  concepts  for  inclusion  irt  the  model.  The 
criteria  used  in  model  development  were: 

.  Hie  model  must  be  as  complete  as  possible  given  observational 
and  conceptual  limitations.  That  is,  the  model  must  be  able 
(id.ally)  to  account  for  or  describe  any  and  all  phenomena 
associated  with  team  performance  in  terms  of  model  concepts. 
Inferences  as  to  the  processes  underlying  team  performance  are 
viewed  as  inferences,  over  and  above  the  descriptive  concepts  of 
the  model. 

.  The  model  must  be  parsimonious.  Only  the  concepts  and 
constructs  that  are  truly  vital  to  describing  team  behavior  and 
.  performance  may  be  included.  These  concepts  must  be  as 
precisely  defined  as  is  possible,  but  definition  by  example  is 
acceptable  in  addition  to  statement  of  a  concept,  for  purposes 
of  clarification. 

.  The  model  must  be  general .  Model  concepts  must  be  based  on 
repeated,  consistent  observation  of  the  phenomenon  the  concept 
deals  with  in  multiple  teams  and/dr  missions.  Concepts  based  on 
single  observations  (i.e.,  one  team  type  performing  one  mission) 
are  not  considered  sufficiently  general  for  inclusion  in  the 
model,  unless  the  concept  is  clearly  generalizable  by  projection 
(e.g.,  it  is  clear  that  the  concept  will  be  useful,  in  general, 
to  describe  team  behavior  and/or  performance). 
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The  concepts  .in«!  constructs  of  tlie  model  presented  in  this  report 
conform  to  the  criteria  Listed  above.  In  addition  to  these  criteria, 
however,  otlier  characteristics  of  the  model  are  discussed  below. 

Limitations  of  the  Model 

The  current  model  of  team  behavior  and  performance  is  in  sosk 
ways  limited.  Some  of  these  limitations  are  deliberate;  that  is,  the 
limitations  are  intrinsic  features  determined  by  the  type  of  model  to 
be  developed.  Other  limitations  are  due  to  limits  in  the  data 
available  for  model  building.  Several  known  limitations  to  the  model 
exist . 

First,  the  observations  on  which  the  model  is  based  have  been 
limited  to  relatively  few  Army  team  types:  Infantry  rifle  squads, 
mortar  squads.  Combat  Engineer  squads  and  platoons,  TOW  crews,  mortar 
and  artillery  fire  direction  centers,  and  assault  ribbon  bridge 
platoons.  Although  these  team  types  (and  missions  observed  for  each 
team  type)  are  felt  co  be  reasonably  representative  of  Army  teams  at 
large,  there  is  the  possiblity  that  some  important  team  phenomena  may 
not  be  present  in  the  teams  and  missions  observed.  Although  the  model 
is  internally  consistent  and  able  to  account  for  team  phenomena  of  the 
team  types  and  missions  that  have  been  observed,  the  model  may  not  be 
complete  or  entirely  externally  consistent.  There  may  be  team 
phenomena  unique  to  team  types  and  missions  other  than  those  observed 
to  build  the  model  for  which  the  amdel  cannot  account  in  its  present 
form.  It  is  believed  that  the  conceptual  structure  of  the  model  is 
flexible  enough  to  allow  additional  team  structure,  behavior,  and 
performance  concepts  to  he  added  to  the  model  reaiily.  The  andel  is 
open-ended ,  as  an  evolutionary  model  ideally  should  be,  allowing  for 
ease  of  expansion  or  modifications  of  the  concepts  that  presently  make 
up  the  model,  in  order  to  accommodate  additional  team  phenomena  that 
may  be  necessary  to  increase  the  generality  of  the  model. 

A  similar  limitation  comes  from  the  fact  that  only  Army  teams  have 
been  observed  in  creation  of  the  model.  This  may  limit  the 
general  inability  of  the  model.  It  is  felt  that  the  model  concepts  are 
sufficiently  general  in  nature  and  scope  that  this  will  not  be  the 
case,  but  no  attempt  has  been  made  to  apply  or  test  the  model  outside 
the  teams  observed  in  developing  the  model.  Should  such  applications 
reveal  a  need  for  expansion  or  modification  of  the  model,  this  can  be 
easily  accomplished. 

Hie  model  offered  in  this  report  is  not  considered  S  ’’final" 
model.  Rattier,  the  model  is  in  the  midst  of  its  evolution  toward 
generality  and  comprehensiveness.  Subsequent  efforts  will  be  directed 
toward  redefining,  sharpening,  and  augmenting  the  model  and  its 
component  concepts  in  the  directions  of  simplicity,  parsimony,  and 
generality.  The  model  itself  will  never  be  considered  "final,"  since 
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the  model  will  always  be  open  to  expansion  and  modification  of  concepts 
to  improve  the  unde r. stand abi it y  and  usability  of  the  model. 

Perhaps  the  most  important  limitation  of  the  model  at  this  point 
is  that  it  is  not  predictive.  It  is  not  presently  possible  to  apply 
the  charactef istics  of  a  given  team  and  team  task  (mission)  under  the 
model  and  derive  predictions  of  the  behavior  or  performance  of  the 
team.  The  model  at  this  time  is  viewed  as  purely  descriptive;  as  a 
"language  of  discourse"  for  the  description  and  study  of  teams,  team 
performance,  and  team  behavior.  Current  knowledge  suggests  that  the 
model  can  ultimately  be  used  in  a  limited  predictive  fashion  to  develop 
hypotheses  about  salient  characteristics  of  the  behavior  and  perform¬ 
ance  of  teams.  No  attempts  to  appty  the  model  in  a  predictive  sense 
have  yet  been  made,  however,  due  to  a  limitation  of  available  data  on 
team  performance. 

A  final  limitation  of  the  present  model  is  that,  as  yet,  no 
specific  attempts  have  been  made  to  use  the  descriptive  concepts  of  the 
model  to  account  for  observed  team  behaviors  and  behavioral  variables. 
In  fact,  it  is  not  possible  at  this  time  to  make  such  attempts,  due  to 
a  lack  of  data.  The  data  that  would  be  needed  to  relate  the  model 
concepts  to  specific  aspects  of  team  performance,  in  an  explanatory  or 
predictive  sense,  do  not  exist  at  this  time,  and  probably  will  not  be 
acquired  in  the  future.  These  data  would  consist  of  descriptions  of 
the  performance  of  a  very  wide  variety  of  team  types,  each  performing 
the  full  spectrum  of  team  missions  (tasks)  appropriate  to  the  team 
type.  The  data  acquired  on  team  performance  and  behavior  would  be 
contrasted  to  other  team  characteristics,  such  as  team  structure  and 
composition,  individual  team  member  proficiency,  and  other  factors,  in 
attempts  to  discover  the  predictive  or  explanatory  value  of  model 
elements  to  team  behavior.  As  mentioned  previously,  it  is  unlikely 
that  such  a  database  of  team  behavior  descriptions  will  be  developed, 
since  the  resources  and  time  required  would  be  prohibitive  for  the 
probable  low Ope rat ional  benefits  to  be  derived  from  such  an  exercise. 
As  a  theory-building  procedure,  however,  this  approach  would  be  totally 
appropriate. 
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MODE!.  OF  TEAM  STRUCTURE,  ORGANIZATION, , AND  BEHAVIOR 


Basic  Definitions  -  Team  and  Team  Mission 


A  major  difficulty  in  integrating  the  existing  literature  on  teams 
and  team  performance  is  the  wide  variety  of  definitions  that  have  been 
used  to  <1  i f ferent iate  teams  from  other  groups.  Few  of  the  definitions 
agree  beyond  the  stipulation  that  a  team  is  composed  of  two  or  more 
people  working  in  some  way  toward  a  common  objective.  For  the  purposes 
of  this  model,  none  of  the  definitions  offered  by  other  researchers  in 
the  team /team  per formanre  field  was  felt  to  he  complete  or  adequate. 
After  considerable  study,  the  following  set  of  characteristics  was 
chosen  to  discriminate  teams  from  other  group  entities: 

.  A  team  is  composed  of  two  or  more  persons.  There  is  no 
arbitrary  upper  limit  on  the  size  of  a  team.  There  are, 
however,  some  practical  difficulties  in  describing  the  behavior 
of  large  teams. 

.  All  members  of  a  team  are  involved  in  a  common  mission,  and  in 
the  context  of  that  mission,  work  to  fulfill  a  common  objective. 
The  term  mission  was  chosen  (rather  than  task)  for  the  model/ 
for  two  reasons.  First,  the  activities  of  military  team  are 
conventionally  termed  missions,  and  use  of  this  term  avoids 
confusion.  Second,  the  term  task  is  employed  in  the  model  to 
characterise  the  behavior  of  an  individual  team  member  in  the 
context  of  the  team  mission,  A  great  deal  of  semantic  confusion 
occurs  when  attempting  to  discriminate  individual  tasks  and  team 
tasks..  Therefore,  it  was  decided  to  use  different  terms  for  the 
two  concepts.  An  individual  performs  tasks  that  contribute  to 
accomplishment  of  a  team  mission. 

.  Hie  responsibility  for  performing  the  various  tasks  that  are 
necessary  to  accomplish  a  team  mission  is  divided  among  the  team 
members.  Each  team  member  performs  one  or,  morn  tasks  in  tha 
team  mission  context. 

.  There  exist  dependencies  among  the  various  roles  involved  in 
performing  any  team  mission.  Dependencies  occur  at  events, or 
times  m  a  mission  where,  in  order  to  continue  with  or  initiate 
mission-related  tasks,  one  or  more  tram  member(s) ' require  input 
of  some  sort  from  one  or  more  other  team  member(s). 

Dependencies  can  be  conceptualized  as  points  of  interaction 
between  the  members  of  a  team  in  mission  context.  In  any  team 
mission,  there  are  a  minimum  of  two  dependencies.  The  absolute 
minimum  case  would  consist  of  one  member  of  a  two-person  team 
signaling  the  initiation  of  the  mission  to  the  other,  the  two 


performing  independent  tasks  required  to  complete  Che  Mission, 
and  the  signaling  of  completion  of  his  assigned  Casks  by  one 
member.  In  reality,  there  are  typically  Many  dependencies 
involved  in  the  performance  of  any  mission  by  any  team. 

Any  entity  that  conforms  to  the  conditions  listed  above  is 
considered  a  team  for  purposes  of  this  model.  These  conditions  arc 
only  boundary,  or  exclusionary,  criteria  for  the  existence  of  *  team, 
however,  and  do  not  provide  any  more  information  about  the  character- 
i  tics  of  an  entity  than  whether  or  not  the  entity  is  a  team. 

A  team  may  be  possessed  of  a  formal  organisational  structure  which 
is  characteristic  of  the  team  typ'  represented  by  the  teaM.  Teams 
which  persist  over  time  will  invariably  have  some  organisational 
structure,  if  only  to  identify  the  various  team  members.  The  teams 
observed  in  creation  of  the  model  all  possess  persistent,  relatively 
consistent  formal  organizational  structures,  since  the  teams  are 
military  units  organized  under  Tables  of  Organization  and  Equipment 
(TOAF).  It  is  possible,  however,  for  a  team  to  be  constituted  ad  hoc 
from  available  personnel  (or  pools  of  personnel  having  various 
characteristics),  perform  a  single  unique  mission,  and  disband,  never 
to  exist  again.  A  team  formed  to  investigate  a  specific  civil  aircraft 
accident  is  an  example  of  this  sort  of  team. 

A  difficulty  closely  related  to  defining  criteria  for  teams  is 
that  of  specifying  criteria  for  defining  a  team  mission.  A  great  many 
different  activities  have  been  included  under  the  label  "team  task1*  in 
the  past,  with  consequent  confusion.  Even  when  a  team  is  definitely 
identified,  many  of  the  activities  performed  by  members  of  the  team  (if 
it  is  not  a  one-shot,  evanescent  team)  are  not  directly  related  to  team 
missions.  For  example,  members  of  an.  assault  ribbcn  bridge  platoon  (a 
team  under  the  criteria  listed  above)  may  go  on  a  physical  training  run 
together.  Is  this  activity  a  mission?  The  cnmmon-senae  answer  is  that 
it  is  not,  but  for  purposes  of  clarity,  some  criteria  are  necessary  to 
bound  the  "team"  activities  of  a  team  from  other  activities  that 
involve  members  of  the  team. 

Several  existing  sets  of  conditions  to  define  tasks  or  missions 
were  considered  for  use.  No  particular  one  of  these  stood  out  as  being 
particularly  appropriate,  and  each  set  had  one  or  more  serious 
limitations.  The  following  conditions  were  finally  chosen  as  a 
practical,  working  set  of  criteria  for  identifying  team  missions: 

.  A  team  mission  is  a  closed-ended  or  hounded  set  of  activities 
performed*  by  the  team.  In  other  words,  there  ls  a  definite 
beginning  and  end  to  any  set  of  activities  that  is  to  be  thought 
of  as  a  team  mission. 

•  A  team  mission  lias  a  definite,  purposeful,  and  achievable 
objective  or  goal.  Attainment  of  the  goal  is  not  necessary  for 
the  activities  involved  to  be  thought  of  as  a  mission,  but  the 
goal  certainly  must  be  reached  for  the  mission  to  be  successful. 


.  \  tf.iiii  mission  must  require  two  or  mire  individuals,  working 
toward  tlif  same  oh  juct  ive  t  with  res|>onsibi  t  it  ies  for  meeting  t  tit* 
nt>  jorl  i ye  il i v ided  among  t earn  members,  to  perform  the  mission  in 
a  reasonahlf  length  of  time.  Many  activities  that  are  team 
mission*  could  hypothel icai ty  be  accomplished  by  a  single 
individual,  at  an  extreme  cost  in  time  to  perform  the  miasicn. 
For  example,  one  person  could  construct  a  log-crib  antivehicular 
obstacle  (normally  constructed  by  a  Combat  Engineer  squad  or 
platoon) — in  about  two  weeks  of  brutally  hard  individual  labor. 

A  competent  squad  cab  construct  such  an  obstacle  in  six  hours. 

Applying  these  three  criteria  to  the  example  presented  earlier 
(the  training  run),  it  is  apparent  that  this  is  not  a  team  mission. 

Hie  example  meets  the  first  two  criteria  (the  training  run  will  be  X 
mi  les;  the  goal  is  to  improve  the  strength  and  stamina  of  team 
members),  but  fails  the  third  criterion.  Any  one  team  member  could  run 
the  prescribed  distant  -  alcne  in  the  same  time  as  the  team  can  run  it 
together,  discounting  differences  in  fitness. 

While  these  criteria  are  adequate  to  differentiate  team  missions 
from  other  kinds  of  activities,  in  general,  the  criteria  are  somewhat 
clumsy  to  apply.  For  example,  when  choosing  among  all  the  activities 
performed  by  members  of  an  Infantry  squad  to  identify  missions  for 
study,  one  might  spend  a  great  deal  of  time  identifying  the  activities 
performed  by  the  team  and  applying  the  criteria  to  decide  which 
activities  are  missions  and  which  are  not.  A  more  practical  means  to 
identify  and  talk  about  potential  missions  is  required. 

Fortunately,  such  a  means  is  available.  In  developing  Army 
Training  and  Evaluation  Plans  (ARTEP*),  the  military  missions  typically 
performed  by  many  team  types  are  identified  and  listed.  Many  of  these 
military  missions  meet  the  criteria  above,  and  are  considered  team 
missions.  In  fact,  alisost  all  of  the  combat-ot iented  ARTEF  missions 
for  the  team  types  studied  meet  the  criteria  for  team  missions. 

To  permit  easy  conceptual ization  in  building  Cha  model  and  to 
avoid  misinterpretation,  the  defined  AKTEP  missions  for  the  team  types 
that  wore  studied  in  model  building  are  simply  thought  of  as  "the 
missions."  All  missions  referred  to  as  examples  in  this  report  are 
ARTKP-de fined  missions  or  part-missions.  The  reader  should  keep  in 
mind  the  general  criteria  for  a  mission  (or  "team  task,")  however,  for 
purposes  of  thinking  about  teams  and  missions  outside  the  military 
context.  Ho*  criteria  are  equally  applicable  to  "team  tasks"  which  are 
encountered  in  non-military  teams. 


Team  Structure  and  Organization  Concepts 

The  remainder  of  this  chapter  is  divided  into  discussion  and 
presentation  of  the  two  critical  aspects  of  th'»  model.  Hie  first: 
section  presents  a  set  of  concepts  which  can  be  used  to  describe  and 
characterize;  the  structure,  organization,  and  other  characteristics  of 
a  team  (or  team  type),  and  to  describe  team  missions.  The  second 
section  presents  concepts  that  are  useful  in  describing  the  behaviors 
of  teams  performing  missions. 

This  separation  was  not  accidental.  It  is  highly  likely  that,  at 
some  future  time,  it  may  be  possible  to  predict  the  behavior  of  teams 
performing  specific  missions  from  the  organizational  and  structural 
characteristics  of  teams  and  of  team  missions.  With  this  in  mind,  it 
is  reasonable  to  think  if, two  sets  of  concepts:  a  potential 
perfomtance/behayior  edictor  set— team  structure  and  mission 
concepts;  and  a  potential  outcome  set— team  behavior  ana  performance 
concepts.  More  important ,  from  the  perspective  of  the  model,  it  is 
vital  to  have  a  complete  understanding  of  the  concepts  of  team 
organization  and  structure  before  considering  concepts  of  tesm 
behavior,  since  the  discussion  of  team  behavior  relies  heavily  on  the 
concepts  of  team  structure  and  organization. 

T-’o  kinds  of  team  "structure**  or  "organization"  are  included  in 
the  model.  The  need  for  two  sets  of  terms  or  concepts  cosies  from  the 
fact  that  there  are  two  kinds  of  team  organisation.  All  of  ehm  team 
types  observed  to  develop  this  model  are  "formally  organized"  teams; 
that  is,  the  teams  exist  within  an  organized  hierarchiai  structure  and 
have  an  internal  structure.  The  structures  that  organise  these  teams 
derive  from  Tables  of  Organization  and  Equipment  (TOfcE)  of  Army  units. 
Under  To&K,  all  teams  of  a  particular  type  have  the  same  formal 
organization,  with  some  minor  variations.  We  term  this  fonsal 
organizational  structure  "nominal  tesm  structure."  Nominal  team 
structure  of  a  team  does  not  change. 

When  performing  particular  missions,  however,  teams  frequently 
organize  in  a  different  f  .ah ion  than  might  be  suggested  by  ths  nominal 
structure  of  the  team  type.  A  team  may  be  understrength,  overstrength 
mission  demands  may  require  peculiar  or  unique,  skills  or  procedures, 
and  so  forth.  Any  or  all  of  these  factors  may  cause  e  teem  to  ba 
organized  in  a  different  fashion  than  reflected  by  the  nominal  team 
structure  in  order  to  accomplish  a  mission.  A  means  was  needed  to 
describe  the  organization  of  a  team  aa  it  actually  performs  a  miaaion, 
since  this  organization  frequently  differs  from  nominal  team  structure 
The  way  a  team  organizes  for  a  particular  mission  is  called  "actual 
team  structure."  To  understand  the  difference  between  the  nominal  and 
actual  team  structure  concepts,  the  reader  may  th.nk  of  nominal  team 
structure  as  a  potential  and  actual  tesm  structure  es  an  expression  or 
elaborstion  of  that  potential. 


Nominal  To am  Structure 


Nominal  team  structure  is,  simply,  a  description  of  the  formal 
organizational  characteristics  of  a  particular  team  type  (under  TO&E, 
all  teams  of  a  particular  type  are  organized  in  similar  ways). 
Describing  the  nominal  structure  of  a  team  consists  of  specifying  the 
following  characteristics  of  the  composition  and  organization  of  the 
team: 

•  Name  or  title  of  the  team,  along  with  the  type  of  unit  in  which 
the  team  exists. 


■  s*ze  the  team  (number  of  members). 

•  Positions  within  the  team.  Each  team  member  occupies  a  position 
in  the  organizat ional  structure  of  the  team.  Two  or  more  team 
members  may  occupy  positions  with  identical  characteristics,  or 
a  team  member  may  occupy  a  unique  position.  Position  codes  or 
abbreviations  may  be  used  to  uniquely  identify  positions.  For 
military  teams,  each  position  is  characterized  by  the  5-digit 
Military  Occupational  Specialty  (MOS)  Code  and  by  any  important 
equipment  (i.e.,  primary  weapon)  associated  with  the  position. 
Other  position  descriptions  for  non-military  teams  could  as 
easily  be  used. 


.  Hierarchial  relationships  among  team  positions.  These 

relationships  are  based  on  the  chain  of  command  in  military 
teams,  but  in  many  cases  can  be  thought  of  as  leader-member 
subordination  relationships.  Also,  some  teams  may  contain 
m- s ted  teams  within  their  nominal  organizational  structures. 
Nested  teams  are  aggregations  of  positions  within  a  team  that 
,  can  be  separately  named  and  identified  (such  as  the  Alpha  and 
llravo  fire  teams  within  an  Infantry  squad),  and  that  frequently 
perform  particular  parts  of  missions  independent  from  the  rest 
of  the  team. 

The  above  are,  the  only  characteristics  needed  to  describe  the 
nominal  structure  of  any  terns  or  team  type,  if  the  team  type  ia 
consistently  organized.  A  nominal  team  structure  can  be  expressed  as  a 
listing  of  positions  with  notations  shout  hierarchial  relationships,  or 
an  organization  chart.  The  authors  prefer  the  latter  form,  since  this 
form  expresses  the  basic  information  about  nominal  team  structure  in  a 
concise  way.  As  examples,  the  nominal  team  structures  of  an  Infantry 
rifle  squad  and  of  a  Combat  Engineer  squad  are  presented  as  Figures  l 
and  2.  Unique  and  replicated  positions  are  indicated  in  both  Figures. 

When  considering  team  types,  rather  than  specific  teams  of  a  given 
type,  there  ire  a  number  of  characteristics  which  are  potentially 
useful  in  discriminating  between  team  types.  These  characteristics  may 
also  bo  related  to  differences  in  the  behavior  or  performance  of 
different  tem  types,  the ,  requirements  for  team  training,  and  other 
factors. 


NOMINAL  TEAM  STRUCTURE  -  INFANTRY  RIFLE  SQUAD  (TYPICAL) 


gure  1.  Nominal  Team  Structure  of  a  Typical  Infantry  Rifle  Squad 


NOMINAL  TEAM  STRUCTURE  -  COMBAT  ENGINEER  SQUAD  (TYPICAL) 


Figure  2.  Nominal  Team  Structure  of  a  Typical  Combat  Engineer  Squad 
(Mechanized) 


Some*  descriptive  characteristics  of  team  types  include  the 

following: 

•  Mission  variety — the  number, of  different  missions  and  mission 
areas  (groups  of  related  missions)  to  which  teams  of  a  given 
typo  may  be  assigned. 

.  Presc r ipt i veness  or  procedural izat ion  of  missions — the  extent  to 
which  a  team  type  follows  well-established  procedures  in 
performing  its  missions,  as  opposed  to  having  the  liberty  to 
perform  missions  in  a  variety  of  ways  appropriate  to  the  mission 
goals  and  conditions.  This  characteristic  roughly  corresponds 
to  the  emerge ' t-establ ished  dimension  of  team  tasks  found 
frequently  ir.  the  literature. 

.  Equipment  dominance  of  particular  team  types.  Some  team  types 
are  dependent  upon  one  or  more  major  items  of  equipment  to 
perform  their  missions  (e.g.,  tank  crews,  mortar  squads),  while 
other  team  types  are  relatively  independent  of  major  items  of 
equipment  (e.g.,  rifle  squads).  This  characteristic  may  be 
highly  correlated  with  the  extent  to  which  missions  are 
procedural  versus  prescriptive  in  nature. 

.Environmental  reactivity  of  missions — the  extent  to  which  the 
performance  of  the  missions  of  a  team  type  are  affected  by 
variations  in  the  physical  and  tactical  environment  in  which  the 
missions  are  performed.  This  characteristic  may  have 
implications  for  the  nature  and  variety  of  team  training 
required  for  particular  team  types. 

Actual  Team  Structure 

While  nominal  team  structure  characterizes  team  types,  or  teams 
out  of  mission  context,  actual  team  structure  deals  with  the  way 
particular  teams  are  organized  and  structured  for  particular  missions. 

A  description  of  the  actual  team  structure  of  a  team  is,  in  essence,  a 
description  of  the  way  in  which  tasks  and  responsibilities  that  are 
required  for  the  successful  completion  of,  the  team  miaaion  are  divided 
among  the  team  members.  Nominal  team  structure  reflecta  the  latent,  or 
potential,  capabilities  of  team  members;  actual  team  atructure  reflecta 
the  actualization  of  some  or  all  of  the  potential  capabilities  of  the 
nominal  team. 

In  nominal  team  structures,  each  team  member  occupies  a  position, 
which  implies  a  set  of  competences  and  capabilities.  The  corresponding 
concept  in  actual  team  structure  is  the  role.  A  role  specifies  a 
defined  set  of  task  requirements  and  responsibilities  in  the  context  of 
a  given  mission. 
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As  in  the  case  of  positions,  roles  may  be  unique,  or  they  may  be 
replicated  in  an  actual  team  structure.  Like  positions,  roles  are 
essentially  agnostic  to  the  individuals  occupying  the  roles.  While  the 
performance  of  different  individuals  in  a  particular  role  may  be  quite 
different,  the  duties  and  responsibilities  of  the  role  are  invariant. 

A  role,  in  general,  may  be  thought  of  as  a  subset  of  a  particular 
nominal-team  position.  The  position  defines  a  .broad ,  potential  set  of 
capabilities  and  skills  that  can  be  applied  to  many  roles  in  the 
context  of  many  team  missions.  Typically,  not  all  of  the  skills  and 
abilities  that  are  associated  with  a  position  are  required  to  fill  a 
particular  role  in  a  given  mission.  A  useful  way  to  conceptualize  the 
relationship  of  position  and  role  is  to  think  of  a  position  as  a  "menu" 
of  skills  and  abilities,  and  a  role  as  a  "meal"  selected  from  the 

ll___  _  _  , ,  II 

menu  . 

Just  as  many  unique  meals  can  be  selected  from  a  menu,  many  unique 
roles'  can  be  constituted  from  the  skills  and  abilities  inherent  in  a 
position.  Each  of  the  roles  is  a  subset  of  the  capabilities  of  the 
position,  but  different  roles  may  be  different  subsets  of  the  position. 
Note  that  the  role  "subsets"  may  overlap.  In  fact,  it  is  probable  that 
each  role  embodies  a  "core"  set  of  skills  and  abilities  of  a  given 
position,  with  a  group  of  particular  "peripheral"  or  "mission-specific" 
skills  and  abilities  added  to  the  "core"  set  to  compose  the  skill  and 
ability  complex  that  is  required  by  a  particular  mission  role. 

Describing  the  actual  structure  a  team  adopts  for  a  particular 
mission  is  very  similar  to  a  nominal  team  structure  description,  with  a 
few  exceptions.  A  simple  actual  team  structure  description  contains 
the  following  elements: 

.  Team  type  name,  plus  any  specific  designations  that  are 

appropriate  to  the  particular  team  being  observed.  For  military 
teams,  this  is  usually  a  complete  description  of  the 
organization  of  the  particular  team  (e.g.,  2nd  squad,  1st 
platoon,  B  Company,  1/505  Infantry,  82nd  Airborne  Division). 

.  Name  of  the  mission  that  the  actual  team  structure  is  adopted 
for  (e.g.,  hasty  attack,  construct  log  crib  ob stac  1  e ,ca  1 1  for 
fire,  etc.). 

.  Listing  of  the  number  ami  identification  of  the  roles  adopted  by 
team  members  in  the  actual  team  structure,  along  with  MOS  and 
primary  equipment. 

.  Descriptions  of  the  responsibilities  and  tasks  of  each  role. 
These  descriptions  are  typically  made  at  a  relatively  global 
level  (e.g,,  the  description  of  the  Infantry  squad  machine 
gunner’s  role  might  be  "operate  M60  machine  gun  in  accordance 
with  squad  tactics").  Task-analytic  or  behavioral-level 


descriptions  are  not  required  for  a  general  description  of 
actual  team  structure,  and  are  not  useful  at  thin  level  of 
description.  It  may  be  that  such  descriptive  detail  will  be 
found  useful  in  the  context  of  developing  team  training,  but 
tliis  speculation  has  not  yet  been  tested. 

.  A  description  of  hierarchial  or  associative  relationships 
between  the  various  roles,  including  the  description  of  any 
nested  teams. 


As  with  nominal  team  structure,  a  useful  method  of  presenting  actual 
team  structure  is  through  the  use  of  organizational  charts,  adding 
appropriate  (separate)  descriptions  of  each  of  the  roles. 

In  describing  a  particular  mission  context,  some  information  in 
addition  to  the  actual  team  structure  has  been  found  to  be  useful. 

Much  of  this  data  is  similar  to  the  additional  data  elements  that  are 
used  to  describe  team  types,  tut  at  a  more  mission-specific. level.  The 
kinds  of  data  that  have  so  far  been  found  useful  in  describing  missions 
are: 

.  Mission  goal— what  the  particular  mission  is  supposed  to 

accomplish  as  an  end  result,  and  any  conditions  that  pertain  to 
the  way  tlu*  goal  is  to  be  achieved.  A  relatively  simple, 
straightforward  statement  of  the  goal  and  conditions  is  all 
that  is  usually  necessary.  For  example,  the  goal  of  a 
reconnaissance  patrol  mission  might  be  characterized  as  follows: 
"Reeonnoiter  the  segment  of  Bear  Creek  from  map  coordinates 
495272  to  497252  to  locate  any  points  where  wheeled  or  track 
vehicles  might  be  able  to  ford  the  creek.  Avoid  engagement  with 
any  enemy  elements  encountered;  if  you  take  fire,  withdraw 
immediately." 

.  Prescriptiveness  or  proceduralizatiog  of  the  particular 
mission — the  extent  to  which  the  mission  follows  established 
procedures  versus  being  heuristic  or  flexible  in  execution. 

.  Equipment  dominance  of  the  mission — how  dependant  the  team  is  on 
major  items  of  equipment,  and  which  roles  are  involved  with  the 
major  equipment  items,  and  in  which  ways;  For  example,  a  Combat. 
Engineer  squad  installing  a  hasty  protective  minefield  is  not 
highly  equipment-dominant:  a  compass,  a  few  marking  stakes  dr 
sticks,  a  shovel,  and  some  mines,  are  the  only  equipment  required 
to  perform  this  mission.  The  same  sqn.'.d  constructing  tank 
ditches  with  bulldozers  or  front-end  loaders  would  be  involved 
in  a  highly  equipment-dominant  mission,  since  it  is  not  feasible 
to  dig  tank  trenches  without  heavy  equipment  in  any  reasonable 
length  of  time.  . 
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»  Environmont.il  ohar.icterist ics  surrounding  mission 

performance — the  characteristics  of  the  physical  and  tactical 
onviornmont  which  may  influence  or  constrain  mission 
performance.  These  characteristics  include  the  necessity  to 
utilize  chemical-radiological  suits  and  masks,  the  presence  or 
absence  of  Opposing  Forces  (OPFOR)  in  the  mission  area, 
availability  of  indirect  fire  or  other  support,  availability  of 
equipment  and  supplies,  team  strength,  terrain,  weather,  and 
illumination  (if  the  mission  is  performed  at  night).  Any  or  all 
of  these  factors  may  have  influence  on  the  way  the  mission  is 
performed,  or  mission  outcome. 


Team  Infrastructure— Nested  Teams 

It  is  frequently  the  case  that  some  defined  and  delimited  subset 
of  the  activities  and  responsibilities  required  to  accomplish  a  mission 
is  performed  by  a  subset  of  the  team,  more  or  less  independently  of  the 
rest  of  the  team.  The  subset  performs  as  though  it  were  a  "team  within 
a  team,"  with  relatively  limited  dependencies  with  the  rest  of  the 
team.  Such  an  entity  is  referred  to  as  a  nested  teem.  A  nested  team 
has  many  of  the  characterist ics  a  team  at  large,  wii.i  some 
restrictions: 

.  A  nested  team  has  quasi-independent  responsibility  for  only  a 
subset  of  the  activities  and  tasks  required  to  accomplish  a 
mission;  the  team  at  large  is  required  to  accomplish  the  entire 
mission. 

.  The  dependencies  of  a  nested  team  with  the  rest  of  the  team  at 
large  typically  occcr  through  only  one  role  (which  may  be 
thought  of  as  the  nested  team  "leader").  In  a  team  which  does 
not  contain  nested  teams,  dependencies  are  generally  not 
restricted  in  this  way.  The  condition  of  having  dependencies 
channeled  through  one  role  is  not  invariable,  but  occurs 
frequently. 

Nested  teams,  in  general,  meet  the  criteria  established  for  teams  at 
large  earlier  in  this  report,  with  the  exception  that  a  nested  teas 
cannot  accomplish  an  entire  mission  by  itself.  The  activities  of  a 
nested  team  within  an  actual  team  structure  have  a  recognizable  goal 
within  the  mission. 

More  than  one  nested  team  may  exist  within  an  actual  team 
structure;  in  fact,  the  actual  team  structure  of  some  teams  is  a  group 
of  nested  teams  with  perhaps  only  one  or  two  role*  not  included  in  one 
nested  team  or  another.  An  example  of  this  situation  (which  also 
illustrates  the  nested  team  concept  in  general)  is  presented 
graphically  in  Figure  3.  This  figure  depicts  the  organization  of  a 
Combat  Engineer  squad  in  the  early  stages  of  constructing  a  log  ctrib 
obstacle.  As  Figure  3  shows,  the  entire  squad  is  organized  into  three 
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ORGANIZATION  OF  COMBAT  ENGINEER  SQUAD  INTO  NESTED  TEAMS 
FOR  A  MISSION  (INSTALLING  LOG  CRIB  OBSTACLE)  - 
EARLY  PHASE  OF  MISSION 


Figure  1.  Example  of  Netted  Teem*  in  «n  Actual  Team  Structure- 
Early  Phaae  of  Mission 


nested  teams,  each  with  its  own  objective  within  the  mission  at  large, 
each  operating  i  ir  a  relat  ively ,  iiulepeiulent  fashion.  One  nested  team, 
supervised  by  the  squad  leader,  has  the  objective  of  preparing  the  site 
for  the  log  crib  obstacle:  digging  post  holes  for  the  upright  logs 
which  will  frame  the  walls  of  the  crib.  A  second  nested  team,  under 
the  assistant  squad  leader,  has  the  objective  of  cutting  logs  for  the 
upright  framing  and  filler  logs  to  build  the  walls  of.  the  log  crib,  and 
for  braces.  The  final  nested  team  has  the  objective  of  providing 
security  and  surveillance  around  the  site  of  the  log  crib.  Unlike  the 
other  two  nested  teams,  the  security  nested  team  is  physically 
distributed  (i.e.,  to  cover  all  approaches  from  the  OPFOR  side  of  the 
site)  and  does  not  have  a  designated  nested  team  supervisor  (in 
practice;,  the  squad  1  nailer  provides  what  supervision  is  required  for 
the  security  nested  team). 

Figure  1  illustrates  the  two  basic  characteristics  of  nested 
teams.  These  are: 

.  nested  teams  are  elements  within  a  team  at  large-  which  are 

organized  like  teams,  but  are  responsible  for  only  a  particular 
(and  defined)  subset  of  the  team's  mission  responsibilities; 
and 

.  the  dependencies  that  the  nested  team  has  with  other  members  of 
the  team  at  large  are  generally  confined  to,  or  channeled 
through,  one  member  of  the  nested  team,  who  may  be  the 
supervisior  of  the  nested  team. 

Thus,  a  nested  team  is  relatively  independent  of  the  remainder  of  the 
team  at  large  while  the  nested  team  is  executing  its  designated 
responsibilities. 

Hu*  composition,  membership  and  existence  of  nested  team 
structures  (within  an  actual  team  structure)  may  be  static  for  the 
duration  of  .1  mission  (i.e.,  the  nested  teams  are  organized  in  the  same 
way  throughout  the  mission),  or  nested  team  structure  may  be  dynamic, 
changing  at  various  points  in  amission.  That  is,  nested  teams  may 
form  at  one  point  in  a  mission,  achieve  their  objectives,  disband,  and 
form  into  other  nested  teams  later,  to  achieve  other  mission-related 
objectives.  An  example  of  dynamic  nested  team  structure  is  provided  by 
the  reorganization  of_the  Combat  Engineer  squad  depicted  in  Figure  3  at 
a  later  phase  of  installation  of  the  log  qrib  obstacle.  The  altered 
nested  team  organizational  structure  is  depicted  in  Figure  4.  Here, 
both  the  digging  and  timber  cutting  nested  teams  that  existed  in  the 
earlier  phase  of  the  mission  have  completed  their  objectives  (all  holes 
dug;  and  all  timber  cut,  trimmed,  and  brought  to  the  site).  The 
personnel  that  were  formerly  members  nf  those  abated  teams  have  now 
been  reorganized  into  two  other  nested  teams:  a  wall-erecting  nested 
team  which  will  erect  and  brace  the  walls  of  the  log  crib  obstacle;  and 
a  fill-gathering  nested  team  which  will  gather  rock  and  dirt  fill  for 
the  log  crib.  Note  also  that  two  of  the  former  members  of  the  security 
nested  team  have  exchanged  nested  team  membership  (and,  hence,  roles) 
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Figure  4.  Example  of  Reorganization  of  Nested  Team  Structure  at  a  Later  Phase 
of  the  Mission  Shown  in  Figure  3. 


with  one  of  the  former  diggers  and  one  of  the  former  timber  cutters  (a 
changed  role  is  designated  by  "EX’*  and  the  abbreviation  of  the  previous 
role  from  Figure  3). 

This  example  is  also  a  good  illustration  of  the  fact  that  the  role 
occupied  by  an  individual  in  a  particular  actual  team  structure  may 
call  upon  different  skills  and  abilities  in  different  parts  or  phases 
of  a  mission.  For  the  purpose  of  describing  a  particular  individual 
role  in  a  dynamic  nested  team  actual  structure,  the  roles  that  a 
particular  individual  occupies  in  the  various  nested  team  must  be 
identified  in  sequence.  For  example,  the  role  labeled  El  in  the 
wal 1 -erecting  party  in  Figure  4  could  be  described  by  the  tasks  that 
individual  performs:  timber  cutter/wall  erector,  or,  in  the  shorthand 
of  the  actual  structure  organisation  charts,  Cl/El.  Note  that  this 
kind  of  description  is  important  when  dynamic  nested  team  structures 
are  part  of  an  actual  team  structure:  the  organization  and  membership 
of  the  various  nested  teams  that  exist  at  succe8sive  phases  of  the 
mission  must  be  described,  and  the  transitions  of  individuals  from  one 
nested  team  to  another  must  be  recorded. 

A  final  word  on  the  subject  of  roles  and  nested  teams:  no  member 
of  a  nested  team  may  be  a  member  of  another  nested  team  at  the  same 
time,  fn  the  example  in  Figure  3,  the  squad  leader  was  said  to  be  in 
' nominal  charge  of  the  security  nested  team  in  addition  to  supervising 
the  digging  nested  team.  When  the  squad  leader  temporarily  leaves  the 
other  members  of  the  digging  nested  team  to  check  on  members  of  the 
security  nested  team,  the  squad  leader  changes  nested  team  membership 
temporarily  and  becomes  a  member  of  the  security  nested  team.  When  the 
squad  leader  returns  to  supervision  of  the  digging  party,  he  once  again 
becomes  a  member  of  the  digging  party  nested  team.  Admittedly, 
shifts  in  dynamic  nested  team  memberships  by  individual  roles,  as 
described,  may  be  difficult  to  visualize.  It  is  useful  to  think  of  the 
squad  leader  as  a  permanent  member  of  one  of  the  nested  teams  (e.g., 
digging),  and  as  a  shallow  or  ghost  member  of  the  other  nested  team, 
occupying  a  role  in  the  second  (security)  nested  team  only 
sporadically.  This  could  easily  extend  to  the  case  where  an  individual 
is  a  ghost  member  of  more  than  one  nested  team,  with  primary  membership 
in  a  single  nested  team.,  If  an  individual  is  not  a  primary  member  of 
one  particular  nested  team  in  such  a  case,  however,  that  individual  is 
not  a  member  of  any  nested  team.  This  may  be  illustrated  by  the  case 
of  a  platoon  sergeant  checking  on  the  performance  of  each  of  the 
independently-operating  nested  teams  during  the  installation  of  a 
minefield— the  platoon  sergeant  interacts  with  each  of  the  nested 
teams  in  turn,  hut  does  not  directly  contribute  to  the  objectives  of 
any  of  the  nested  teams.  Thus  he  fs  a  member  of  none  of  the  nested 
teams. 

Up  to  this  point,  nested  teams  have  been  discussed  primarily  in 
the  context  of  actual  team  structure.  It  is  possible  for  nested  teams 
to  exist  in  nominal  team  structure,  as  well,  as  mentioned  in  the 
discussion  of  nominal  team  structure.  Tn  this  case,  Che  nested  teams 
remain  constant  across  all  the  missions  that  may  be  performed  by  a 
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particular  team  type.  While  the  internal  organization  of  the  nominal 
nested  teams  may  change  in  response  to  the  demands  of  various  missions, 
the  basic  structure  and  boundaries  of  a  nominal  nested  team  structure 
do  not  change.  An  example  of  a  nominal  nested  team  structure  for  an 
Assault  Ribbon  Bridge  Platoon  is  presented  as  Figure  5.'  Here,  three 
nested  teams  exist  within  the  nominal  organization  of  the  team  at 
large.  This  nominal  organization  persists  across  all  the  missions 
performed  by  the  platoon,  even  though  the, actual  team  structure  of  the 
platoon  may  change  from  the  nominal  nested  structure  in  various 
miss  ions . 


A  final  point  qn  the  subject  of  nested  teams:  nested  teams  may 
exist  at  more  than  one  level  of  nesting.  In  other  words,  nested  teams 
may  exist  within  nested  teams,  to  any  number  of  levels  of  nesting. 

This  situation — multiple  levels  of  nesting— is  not  likely  to  occur  in 
numerically  smaller  team  types  (e.g. ,  Infantry  or  Combat  Engineer 
squads),  but  can  be  expected  to  occur  in  larger  team  types  (platoons, 
e‘.c.),  which  have  more  complex  and  demanding  missions  with  many 
ii ternal  objectives  or  goals  which  must  he  achieved  simultaneously. 


ASSEMBLY  SECTION 


Team  Behavior  Concepts 


The  previous  section  presented  concepts  that  can  be  used  ta 
conceptualize  both  the  nominal  and  actual  structure  of  teams  and  team 
types.  Tn  addition  to  the  structural  and  organizational 
characteristics  of  teams,  it  is  critical  to  have  a  way  of  meaningfully 
characterizing  the  behavior  of  teams  as  they  perform  missions.  The 
ability  to  describe  the  behavior  of  teams  in  a  consistent  and 
understandable  way  can  provide  a  tool  to  be  used  in  several  important 
developments,  including: 

.  a  means  to  evaluate  the  performance  of  teams  on  consistent, 
valid,  and  meaningful  dimensions; 

.  ways  to  evaluate  the  commonality  of  behaviors  and 
characteri sties  of  various  teams,  to  discover  important: 
variables  which  character ize  critical  differences  between  team 
types  and  th<-ir  performance; 

.  techniques  to  identify  generic  and  specific  training 

requirements  for  teams  in  general,  team  types,,  and  specific  team 
missions; 

.  a  theory  of  team  performance  which  can  link  and  explain 
characteristics  and  effects  of  team  organisation,  structure, 
missions,  and  team  behavior  in  a  coherent  and  predictive  way. 

Hits  section  describes  a  simple,  but  very  powerful,  set  of 
concepts  for  describing  the  behavior  of  a  team  performing  any’  of  its 
missions.  As  was  mentioned  in  the  discussion  of  the  development  of  the 
model,  these  concepts  are  the  result  of  a  synthesis  of  observation  and 
logical  analysis  of  the  behaviors  of  several  types  of  team  and  of 
missions  performed  by  each  team  type.  The  concepts  presented  are 
internally  complete  and  coherent  (i.e.,  all  of  the  behaviors  of  teams 
and  team  members  performing  their  missions  can  be  adequately  described 
by  using  these  concepts).  However,  there  is  no  assurance  that  theie 
concepts  can  be  used  to. describe  all  possible  behaviors  of  all  possible 
teams.  With  this  caution  in  mind,  the  following  discussion  is 
offered. 

The  basic  premise  of  this  model  of  team  behavior  is  simply  that  ' 
there  are  only  two  kinds  of  observable  phenomena  that  occur  in  the 
performance  of  any  mission  by  any  team:  the  tasks  performed 
autonomously  by  the  individual  members  of  the  teaai,  and  the  dependency 
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events  that  occur  be L ween  team  members.  Tints,  describing  the 
individual  tasks  that  are  performed  by  each  role  incumbent  and 
characterizing  the  dependencies  that  occur  between  roles  completely 
describes  the  behavior  of  a  team  performing  a  mission.  Description  of 
individual  tasks  involved  in  a  team  mission  is  relatively  simple; 
characterizat ion  of  dependencies  is  somewhat  more  difficult. 

Hie  concept  of  dependency  is  a  synthesis  of  many  different 
attempts  in  previous  work  to  characterize  the  ways  in  which  members  of 
teams  interact  in  performing  team  tasks  or  missions.  Previous 
investigators  have  concentrated  on  such  factors  of  team  member 
interaction  as  coordination,  communication,  activity  pacing,  control, 
and  so  forth.  For  whatever  reason,  a  critical  underlying  unity  in 
these  concepts  has  remained  unrecognized. 

This  unity  is  made  apparent  when  the  nature  and  purpose  of  teams 
is  considered.  A  team  is  required  to  perform  a  particular  task  or 
mission  when  the  number  or  criticality  of  activities  that  must  be 
performed  to  accomplish  the  task  or  mission  goal  is  too  great  to  be 
accomplished  by  one  person  acting  alone  in  a  reasonable  period  of 
time  (recall  the  previous  defining  characteristics  of  a  mission).  The 
responsibility  for  performing  the  component  activities  or  tasks  of  the 
mission  is  thus  divided  between  two  or  more  people.  Since  the 
responsibilities  for  accomplishing  the  mission  all  relate  to  the  common 
goal,  each  member  of  a  team  is  therefore  dependent  upon  other  team 
members,  in  the  global  sense  that  all  team  members  must  fulfill  their 
responsibilities  in  order  to  achieve  the  ultimate  goal  of  the  team 
mission.  This  establishes  that  there  is  a  global  dependency  among  team 
members  engaged  in  a  particular  mission.  This  would  be  the  only 
explanatory  concept  necessary  if  each  team  member  was  able  to  pursue  a 
defined  subset  of  mission  tasks  independently,  with  the  successful 
accomplishment  of  the  mission  requiring  only  that  each  team  member 
complete  his  assigned  tasks.  This  may  even  be  the  case  in  some  , 

situations. 

In  the  real  world,  however,  team  members'  Casks  frequently  require 
input  resulting  from  the  activities  of  other  team  members  in  order  that 
the  tasks  he  completed  or  initiated.  Take,  for  example,  the  following 
two  situations  in  the  performance  of  a  fire  mission  by  a  mortar  squad 

.  Dependency  for  task  initiation:  The  dquad  leader  receives 
firing  data  via  telephone  from  a  fire  direction  center.  If  the 
squad  loader  fails  to  relay  this  data  to  other  members  of  the 
MFS  team,  the  tasks  that  must  be  accomplished  to  get  mortar 
rounds  out  of  the  tube  cannot  even  be  initiated,  since  Che  other 
team  members  are  unaware  that  their  tasks  need  to  be  performed, 
All  of  the  other  team  members  are  clearly  dependent  upon  the 
squad  leader  to  initiate  the  various  interrelated  tasks  of 
laying  the  mortar  and  preparing  rounds  to  be  fired. 


.  Dependency  for  task  continuation  or  completion:  One  ra«rmber  of 
.1  mortar  si|ua<t,  tin-  ammunition  handler,  prepares  mortar  rounds 
by  installing  and  setting  the  proper  fuse  and  placing  the 
correct  amount  of  propellant  charge  on  each  round*  If  the 
ammunition  handler  fails  to  prepare  a  round  or  make  the  round 
available  to  the  assistant  gunner  (who  places  the  round  in  the 
mortar  tube),  the  other  members  of  the  team  cannot  continue 
their  individual  tasks  involved  in  firing  the  weapon,  even 
though  they  may  have  completed  the  gun-laying  tasks  for  which 
they  are  responsible,  independent  of  the  performance  of  Che 
ammunition  handler.  The  other  members  of  the  team  are  clearly 
dependent  upon  the  ammunition  handler's  tasks  in  order  to 
continue  with  their  tasks  or  to  complete  tasks'  which  are 
suspended  pending  the  ammunition  handler's  completing 
preparation  of  the  round. 

These  examples  point  out  the  critical  aspect  of  dependencies, 
which  is  that  a  dependency  is  basically  no  more  than  the  provision  of 
input  to  the  incumbent  of  a  role.  The  input  is  necessary  for  the  role 
incumbent  to  initiate,  continue,  or  complete  tasks  that  are  the 
responsibility  of  that  role.  This  is  the  underlying  unity  behind  the 
wide  variety  of  concepts  and  explanations  of  the  interactions  of  team 
members  which  have  been  generated  in  the  past.  Team  members  must 
provide  the  necessary  inputs  on  which  other  team  memberr  depend  for 
their  individual  task  performances,  when  the  inputs  are  needed.  In  the 
abstract,  the  type  of  input  is  not  relevant,  only  the  fact  that  the 
performance  of  a  team  member  in  some  way  depends  on  the  input. 

In  the  practical,  real  world  of  teams,  however,  it  is  not 
sufficient  only  to  establish  the  existence  of  dependencies.  To  be 
useful,  dependencies  must  be  character ized  and  put  in  context  both  of 
the  team  mission  ns> a  whole  and  of  the  tasks  of  the  team  members  who 
are  involved  in  dependencies.  This  means  that  the  sequences  of 
individual  tasks  of  the  various  team  members  must  be  described  at  some 
level  of  detail.  This  leads  back  to  the  basic  premise  at  the  beginning 
of  this  section:  to  describe  a  mission,  one  must  describe  individual 
tasks  and  dependencies. 

During  the  process  of  developing  this  model,  a  convention  fbr 
describing  and  characterizing  individual  tasks  and  dependencies  was 
developed..  Basically,  the  individual  tasks  or  activities  of  each  team 
member  are  listed  side  by  side  on  a  common  scale,  preserving  the  time 
or  phasing  relationships  between  the  tasks  of  each  role.-  Dependencies 
are  entered  as  links  between  each  of  the  roles  involved  in  the 
dependencies.  This  method  allows  one  to  create  a  time-line  picture  Of 
an  entire*  mission  that  includes  information  about  which  team  members 
performed  which  tasks,  approximately  when  tin*  tasks  were  performed  and 
how  long  the  tasks  took,  which  dependencies  occurred  between  which 
team  members,  and  how  the  dependencies  relate  to  the  team  members' 
individual  tasks.  An  incomplete  diagram  of  a  very  simple  mission 
performed  by  a  team  of  three  people  is  offered  in  Figure  6  as  an 
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example  of  this  kind  of  description.  This  diagram  shows  that  each  team 
member  has  several  individual  tasks  and  is  dependent  on  each  of  the 
other  team  members  for  inputs  (instructions,  tools,  materials, 
subassemblies)  that  are  needed  to  fulfill  his  own  responsibilities. 

It  was  stated  earlier  that  more  than  just  the  simple  existence  of 
a  dependency  between  two  or  more  roles  must  be  specified  when 
discussing  dependencies.  To  completely  characterize  a  dependency  in  a 
meaningful  way  requires  the  following  information: 

.  identifying  the  initiator  or  initiators  of  a  dependency:  the 
role(s)  that  initiate  the  dependency,  or  provide  input  to 
another  role  or  roles; 

.  identifying  the  recipienc(s)  of  a  dependency:  the  role  or  roles 
that  receive  the  input; 

.  identifying  and  characterizing  the  type  of  dependency;  that  is, 
classifying  the  input  or  dependency  element  that  is  provided; 

.  identifying  and  characterizing  the  purpose  of  certain  types  of 
dependencies; 

.  identifying  and  characterizing  patterns  of  related  dependencies 
(i.e.,  cases  where  two  or  more  initiators,  recipients,  or 
dependency  elements  are  involved) 

Identifying  the  initiators  and  recipients  of  dependencies  is  a 
simple  process:  the  roles  are  listed,  or  identified  by  some  sort  of 
symbols  A  convention  which  has  been  adopted  is  to  use  a  flow  arrow  to 
show  the  flow  of  the  dependency  element  from  initiator  to  recipient  in 
the  simple  case: 

Initiator  (I)  Element^  Recipient  (R)- 

If  multiple  initiators,  recipients,  or  elements  are  involved,  there  is. 
a  dependency  pattern,  for  which  special  descriptive  symbols  have  been 
developed.  Dependency  patterns  will  be  discussed  in  detail  in  a  later 
segment  of. this  report. 

Identifying  and  characterizing  dependency  types  and  purposes  can 
be  accomplished  in  a  similar  fashion;  i.e.,  simply  writing  down  or 
abbreviating  the  kind  of  dependency  element  and  the  pr-pose  that  the 
element  serves.  In  practice,  a  limited  number  of  type  and  piirpose 
categories  serve  to  characterize  almost  all  dependencies  and  patterns 
that  have  been  observed  in  creation  of  this  model.  The  categories  and 
abbreviation  symbols  that  were  created  for  these  characteristics,  are 
detailed  below. 
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In  observations  made  to  date,  three  general  classes  or  types  of 
dependency  elements  have  been  identified,  each  of  which  is  divided  for 
clarity  and  specificity  into  two  or  more  subclasses.  Each  subclass  is 
conventionally  considered  as  a  dependency  "type"  for  purposes  of  the 
model.  Table  2  presents  the  dependency  types  and  subtypes  currently 
used  in  the  model.  Each  of  the  dependency  types  is  discussed  below. 


Communicative  Dependencies.  This  label  is  somewhat  misleading  as, 
in  fact,  all  dependencies  serve  a  "communicative"  purpose;  i.e.,  reduce 
uncertainty  about  the  next  actions  of  the  recipient  role(s)  or  the 
mission  outcome.  The  title  "communicative  dependencies"  is,  however, 
appropriate,  since  the  primary  elements  of  these  types  of  dependencies 
are  oriented  directly  toward  communication  of  verbal  information,  or 
analogues  or  signals  that  parallel  verbal  communication.  Conversely, 
the  "information"  conveyed  by  other  types  of  dependencies  are  not' 
directly  communicative;  rather,  their  message  is  indirect. 

Communicative  dependencies  are  divided  into  two  major 
subtypes — verbal  and  nonverbal — and  the  verbal  subtype  is  further 
divided,  as  illustrated  in  the  following  discussion. 

Verbal  communicative  dependencies  are  dependencies  in  which  the 
information-bearing  dependency  element  is  linguistic— i.e. ,  derived 
from  oral  or  written  speech.  There  are  two  major  types  of  verbal 
communicative  dependencies: 

.  Direct ,  or  nonmed iated  verbal  communicative  dependencies  (type 
abbreviation — CD).  Dependency  elements  consist  of  speech 
between  two  or  more  role  incumbents.  •  Equipment  (e.g.,  non-coded 
voice  ifadio,  or  telephone)  may  be  involved  in  the  transmission 
of  speech  from  initiator(s)  to  recipient(s) ,  but  the 
communication  must  be  spoken  language.  ‘ 

.  Indirect ,  or  mediated  verbal  communicative  dependencies  (type 
abbreviat ion — Cl) .  fn  this  type  of  dependency.,  the  information 
in  the  dependency  element  is  transmitted  between  initiator(s) 
and  rdcipient(s)  indirectly,  or  by  abstractions  of  spoken 
language.  Some  examples  of  mediating  schemes  that  are  possible 
are: 

-  written  messages 

-  courier  with  memorized  message 

-  wire  teletype-  or  telex 


encoded  voice  rad  id  messages  (e.g.,  CEOI) 
computer  message-forwarding  systems 


Table  2 

DEPENDENCY  TYPES,  ABBREVIATIONS,  AND  EXAMPLES 

COMMUNICATIVE  DEPENDENCIES  -  ELEMENT  IS  INFORMATION 
Verbal  Communicative  Dependencies  -  Speech  or  Writing  , 

Direct  Verbal  (CD) 

—  Direct  speech,  voice  radio,  telephone 
Indirect  Verbal  (Cl) 

-  Written  message,  courier  with  memorized  message,  teletype/telex,  computer 
message  systems,  Morse  code  (CW  radio,  lights,  flags) 


Nonverbal  Communicative  Dependencies  (CN) 

Standard,  widely-used  signaling  systems 

-  Hand  signals,  light  signals,  flag  signals 

Signal  systems  unique  to  particular  teams  but  consistent  over  missions 

-  Unique  hand  signals,  formations,  body  movements,  forms  of  physical  contact,  etc. 

Temporary  mission -siiccific  messages 

—  Shift  covering  fire  on  violet  smoke,  etc. 


PRODUCT  DEPENDENCIES  -  ELEMENT  IS  PHYSICAL  PRODUCT  OR  COMPLETION  OF 
PROCEDURE  OR  TASK 

Physical  Product  Dependencies  (PP) 

—  Dependency  element  is  a  tangible  physical  object 

Procedural  product  dependency  (dependency  element  is  the  completion  of  a  procedure,  task, 
or  activity) 

Mediated  procedural  product  dependency  (PI) 

-  Procedure  performed  by  equipment  but  controlled  by  role  ineumbent(s) 

Nonmediated  procedural  product  dependency  (P2) 

'  -  Procedure  performed  by  role  incumbent(s)  using  passive  items  of  equipment 

VIRTUAL  DEPENDENCIES  -  DEPENDENCY  ELEMENTS  ARE  IMPLIEO,  MULTIPLE 
ROLES  INVOLVED 

Type  I  Virtual  Dependency  (VI) 

-  Identical  tasks  performed  concurrently  by  several  role  incumbents  acting 

-  quasi- independently 

Type  II  Virtual  Dependency  (V2) 

—  Collection  of  related  tasks  or  activities  carried  out  by  a  group  of  role 
incumbents  without  specific  assignment  of  roles  to  tasks 


Morse  code  (CW  radio.  Hags,  telegraph,  blinker  signals, 
etc.) 


Nonverbal  communicative  dependencies  (type  abbreviation— CN)  are 
dependencies  in  which  nonlinguistic  symbols  (gestures,  events,  etc.) 
are  substituted  for  linguistic  symbols  in  the  information-bearing 
dependency  element(s).  On  the  basis  of  team  behavior  observation, 
three  distinct  kinds  of  nonverbal  communicative  dependencies  have  been 
identified.  Although  they  are  not  separate  dependency  categories  in 
the  model,  the  three  kinds  of  nonverbal  communicative  dependencies  that 
have  been  observed  are  listed  below  as  examples: 


.  Widely  standardized  and  used  nonverbal  signaling  or  message 
systems.  These  are  kinds  and  systems  of.  signals  that  are  found 
to  be  used  in  a  wide  variety  of  team  types,  missions,  and 
contexts.  Some  examples  are: 

-  hand  signal  systems  (e.g.,  tactical  movement  control 
signals  used  in  combat,  standardized  signals  used  for 
marshalling  aircraft,  standard  signals  used  for  control 
of  boat  movements,  etc.) 

-  light  signals  (e.g.,  ships'  running  and  marker  lighting 
protocols,  lights  used  from  control  toilers  to  control 
aircraft  ground  movements) 

-  flag  signals  (e.g.,  mechanized  or  Armor  3-flag  system, 
etc.) 

-  other  types  of  widely-accepted  nonlinguistic  signal  or 
symbol  systems 

.  Signaling  or  message  systems  adopted  for  general  (i.e., 
across-raission)  use  by  particular  teams.  These  are  signals  or 
signal  systems  that  a  particular  team  adopts  for  its  own  use  or 
convenience  and  uses  as  a  regular  part  of  its  nonlinguistic 
communicative  protocol.  Some  examples: 

-  hand  signals  unique  to  a  team;  e.g.,  the  use  of  an 
unusual  gesture  to  indicate  the  presence  and  direction  of 
OPFOR,  by  a  particular  Infantry  squad 

-  direct  physical  contact;  e.g.,  tapping  vehicle  driver  on 
one  or  the  other  shoulder  or  the  top  of  the  helmet  with  a 
stick  to  signal  Ohange  of  direction  or  "stop" 

-  positions  of  particular  team  members  with  respect  to  the 
rest  of  the  team 

-  movement  of  personnel 

-  etc. 


.  Special  signals  adopted  for  particular  purposes  for  one  mission 
only  by  a  particular  team.  These  are  agreed-on,  prearranged 
symbols  or  events  that  are  used  to  signal  or  signify  specific, 
preplanned  actions.  For  example,  a  rifle  squad  on  a 
movement-to-contae’t  mission  may  prearrange  that  the  release  of  a 
red  smoke  grenade  after  enemy  contact  is  a  signal  to  the  "fire" 
team  to  lift  or  shift  covering  fire  so  that  the  maneuver  team 
can  assault  an  enemy  position  without  fear  of  friendly  fire. 

Those  categories  are  adequate  to  describe  and  characterize,  at  a 
general  level,  the  communicative  dependencies  that  have  been  observed. 
It  may  be  that  future  applications  or  extensions  of  the  model  may  , 
require  more  specific,  highly  detailed  schemes  for  classifying 
communicative  dependencies  to  serve  particular  purposes.  When,  and  it, 
such  expansions  or  refinements  occur,  it  is  suggested  that  the  basic 
types  of  communicative  dependencies  listed  above  be  preserved,  and 
subcategories  created as  needed,  to  maintain  a  coherent  structure  for 
future  models  or  extensions. 

Product  Dependencies .  With  product  dependencies,  the  dependency 
element  that  passes  between  initiator(s)  and  recipient(s)  consists  of  a 
physical  or  logical  product  of  the  activities  of  the  initiator(s)  of 
the  dependency.  Dependency  types  in  this  class  are  distinguished  by 
the  general  type  of  product — a  physical  entity  (physical  product 
dependency)  versus  the  completion  of  a  procedure  or  task  (procedural 
product  dependency). 


Physical  product  dependencies  (type  abbreviation-PP)  are  those 
dependencies  where  the  dependency  element  is  a  tangible, 
physical  item  of  some  sort.  An  example  of  a  physical  product 
dependency  was  provided  earlier  (the  preparation  of  a  mortar 
round  for  firing  by  the  ammunition  handler  of  a  mortar  squad). 
When  the  round  is  made  available  to  the  assistant  gunner  for 
insertion  in  the  mortar  lube,  a  physical  product  dependency 
occurs.  Note  that  not  all  transfers  of  physical  i‘-  *108  from  one 
team  member  to  another  djjritig  the  performance  of  k  mission  are 

product  dependencies.  For  example,  one 
personal  weapon  to  another  member 


mission-related  physical 
team  member  may  hand  his 


during  a  rest  break  so  that  the  first  team  member  can  use  both 


hands  to  clean  hie  hoots 
other  team  member  is  riot 


t  1 


dependency  element  is 
by  team  members  who  ini 
the  procedure  or  task  mi 


of  mud.  Handing  the  weapon  to  the 
necessary  to  initiate  or  facilitate  a 
task  on  the  part  of  either  team  member;  therefore,  it  is. not  a 
dependency  at  all  (wiles;,  of  course,  the  mud  on  the  boots  of 
the  team  member  who  hand;  the  rifle  off  prevents  him  from 
walking  or  keeping  up  with  the  rest  of  the  squad).  Careful  and 

often  needed  to  discriminate  apparently 
minor  physical  product  dependencies  from  incidentals  such  as 
that  described  above. 


Procedural  product  dependencies  are  dependencies  where  the 


e  completion  of  some  procedure  or  task 
iate  the  dependency.  The  completion  of 
ii8t  be  necessary  to  enable  the 
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dependency  recipient  rple(s)  to  initiate,  complete,  or  continue 
tasks  or  .activities  for  which  the  rccipieut(s)  are  responsible 
in  context  of  the  mission  being  performed.  Procedural  product 
dependencies  are  divided  into  two  types: 

-  Mediated  procedural  product  dependencies  (type 

abbreviation-Pl)  are  dependencies  where  the  completion 
of  the  procedure  or  task  (the  dependency  element)  is 
wholly  or  partially  accomplished  by  one  or  more  active 
items  of  equipment.  That  is,  the  equipment  used  by  the 
dependency  initiator(s)  performs  some  or  all  of  the 
procedure.  An  example  of  this  type  of  dependency  is  the 
use  of  a  fire  direction  computer  (FADAC)  by  a  member  of  a 
Fire  Direction  Center  (FDC)  team.  The  operator  of  the 
FADAC  enters  data  on  target  location  and  altitude  and 
shell  type  into  the  computer  via  a  keyboard.  The  FADAC 
computer  processes  the  data  entered  according  to  a 
defined  algorithm  and  displays  firing  data,  which  are 
then  relayed  by  the  operator  to  the  gurt  captains  (the 
actual  relay  of  the  firing  data  is  a  verbal  communicative 
dependency  which  is  associated  with  the  procedural 
product  dependency).  The  equipment  plays  an  active  role 
in  completing  the  procedure. 


-  Nonmediated  procedural  product  dependencies  (type 
abbreviat ion-P2)  are  procedural  product  dependencies 
where  completion  of  the  task  is  accomplished  by  human 
action  alone,  even  though  the  procedure  may  involve 
passive  items  of  equipment.  For  example,  an  RTO 
(radio-telephone  operator)  setting  a  frequency  on  a 
PRC-77  radio  so  that  a  platoon  leader  can  communicate 
with  his  company  commander  is  engaged  in  an  activity  that 
leads  to  a  P2-type  dependency,  at  its  completion.  Unless 
the  frequency  is  set  properly,  communication  cannot  be 
established,  hence  there  is  a  P2  dependency  between  the 
RTO  and  the  platoon  leader,.  The  radio  itself  is  passive 
in  the  procedure  of  frequency  setting.  Another  example 
of  a  P2-type  dependency  is  provided  by  the  interaction 
between  the  two  fire  teams  (nested  teams)  of  a  rifle 
squad  engaged  in  assaulting  an  objective.  One  fire  team 
(the  maneuver  team)  moves  to  flank  the  OPFOR  position, 
while  the  other  (fire  team) . lays  down  suppressive  fire  on 
the  enemy  position,  but  lifts  fire  (i.e.,  stops  firing) 
when  the  maneuver  team  is  in  position  and  ready  to 
assault  the  OPFOR  position.  The  fire  team's  fire  must  be 
lifted  before  the  maneuver  team  can  assault  the  OPFOR 
position.  The  lifting  of  fire  by  the  fire  team  is  a 
dependency  which  allows  the  maneuver  team  to  assault 
without  fear  of  friendly  fire.  The  (collective) 
dependency  initiators  are  the  fire  team  members,  the 


rec  intents  (again,  collective)  arc  the  maneuver  team 
members,  and  the  dependency  element  is  the  lifting,  or 
cessation,  of  fire. 

As  in  the  case  of  communicative  dependencies,  these  categories  or 
types  of  product  dependencies  are  adequate  to  characterize  all  of  the 
product-type  dependencies  that  have  been  observed  in  model  building. 
Again,  more  detailed  categorization  of  types  may  be  required  for 
possible  future  applications  or  extensions  of  the  model  to  particular 
cases.  In  describing  missions,  however,  it  has  been  found  that 
identifying  the  physical  dependency  element  in  a  PP-type  dependency  is 
adequate  to  describe  the  dependency.  Also,  the  activities  or  tasks 
performed  by  dependency  initiators  in  Pi-  and  P2-type  dependencies 
often  serve  to  completely  specify  the  kind  of  dependency  elements  that 
exist  in  these  dependency  types. 

Virtual  Dependencies.  Virtual  dependencies,  in  addition  to  being 
of  a  distinctly  different  sort  from  communicative  and  product 
dependencies,  are  always  patterned  dependencies  (i.e.,  more  than  one 
dependency  element  is  involved).  Virtual  dependencies  exist  where  the 
responsibilities  of  several  team  members  (roles)  are  apparently 
identical  and  the  team  members  are  involved  in  highly  similar 
activities  (Type  I  Virtual  dependency),  or  where  several  team  members 
share  the  responsibility  for  performing  a  collection  of  tasks  or 
activities  without  the  tasks  being  assigned  specifically  or 
consistently  to  the  individual  roles  (Type  II  Virtual  dependency). 

.  The  generic  term  virtual  dependency  was  chosen  for  this  kind  of 
team  phenomenon  following  the  same  logic  as  in  the  choice  of  the  term 
"virtual  memory"  in  computing  jargon.  In  computing,  virtual  memory 
refers  to  a  logical  construct:  the  existence  of  parts  of  a  computer 
program  or  data  space  which  do  not  have  existence  in  the  physical 
computer  memory  on  a  continuous  basis.  These  parts  of  the  program  are 
brought  into  actual  physical  memory  only  at  times  when  they  are  needed; 
otherwise,  their  existence  is  virtual,  rather  than  actual,  in  the 
computer  hardware.  Thus,  the  virtual  pares  sf  the  program  are  not  ' 
observable  by  inspection  of  the  contents  of  the  computer  memory  at  such 
times. 

As  with  any  analogy,  this  case  is  only  approximate.  However, 
there  .exists  a  parallel  between  computer  virtual  memory  and  virtual 
dependencies:  while  virtual  memory  has  no  physical  existence,  the 
elements  of  a  virtual  dependency  are  not  observable.  In  both  cases, 
the  "virtual" .entity  is  only  implied  anil  must  be  inferred  from  other 
phenomena. 

As  stated  earlier,  two  types  of  virtual  dependencies  have  been 
identified.  The  following  discussion  presents  the  distinction  between 
the  two  types  in  detail.  Recall  that  all  virtual  dependencies  are 
considered  to  be  patterned,  and  have  multiple  elements.  In  addition, 
all  participants  in  a  virtual  dependency  are  considered  to  be  both 
dependency  initiators  and  dependency  recipience. 


c 


Type  1  Virtual  dependency  (type  abbreviat ion -V 1) .  In  this  type 

of  dependency,  a  single  task  or  responsibility  is  shared  by 
several  roles  on  a  continuous  basis.  The  team  members  involved 
in  a  Vl-type  dependency  perform  very  similar  activities  directed 
toward  the  same  general  objective.  The  classic  example  of  a 
Type  I  virtual  dependency  is  an  Infantry  squad  during  movement 
in  tactical  eondif'ons.  In  this  case,  each  of  the  squad  members 
has  responsibility  to  maintain  required  separation  from  other 
squad  members  (to  avoid  many  people  being  simulatneously  hit  by 
automatic-weapon  or  indirect  fire),  and  to  maintain  surveillance 
of  the  area  around  the  squad  for  signs  of  the  enemy.  The  squad 
members  jointly  share  the  responsibility  for  maintaining 
formation  and  survel lance  during  movement,  providing  security 
simultaneously  for  themselves  and  all  other  members  of  the 
squad,  on  a  continuous  basis.  There  is  considered  to  be  a 
cont inuous  dependency  element  between  each  pair  of  squad 
members,  even  though  no  actual  dependency  element  can  be 
observed  in  this  situation  (nor  in  any  other  Type  I  Virtual, 
dependency).  All  of  the  participants  in  a  Type  I  Virtual 
dependency  are  considered  to  be  both  dependency  initiators  and 
dependency  recipients,  continuously. 

Type  11  Virtual  dependency  (type  abbreviation-V2) .  This  type  of 
virtual  dependency  is  clearly  distinct  from  the  Type  I  Virtual 
dependency  and  from  communicative  and  product  types.  In  this 
case,  a  number  of  team  members  jointly  share  the  responsibility 
for  the  completion  of  a  number  of  related  (but  not  identical) 
activities  or  casks.  No  specific  responsibility  for 
accomplishing  any  of  the  group  of  tasks  is  assigned  consistently 
to  any  of  the  team  members  who  are  jointly  responsible  for 
completing  the  task.  An  example  of  this  type  of  virtual 
dependency  is  provided  by  the  erection  of  camouflage  by  members 
of  a  TOW  crew  after  the  weapon  has  been  set  up  in  place.  The 
crew  members  jointly  have  responsibility  for  setting  up 
camouflage  nets,  cutting  brush,  building  protective  walls  around' 
the  weapon,  etc.,  but  none  of  these  activities  is  specifically 
assigned  to  any  one  crew  member  on  any  consistent  basis.  Each 
crew  member  is  aware  of  what  must  be  done  and  performs  some 
subset  of  the  tasks  required  to  improve  the  position,  but  does 
not  always  perform  the  same  subset  of  the  tasks.  Unlike  the 
Type  I  virtual  dependency,  a  Type  II  virtual  dependency  does  not 
typically  extend  over  a  period  of  time.  Rather,  the  activities 
that  make  up  a  Type  II  virtual  dependency  are  generally  closely 
related  to  one  component  goal  or  objective  of  the  mission,,  as  in 
the  case  of  erecting  camouflage  discussed  above,  or  in  the  case 
of  four  members  of  a  combat  engineer  platoon  unloading  equipment 
from  a  truck  and  establishing  mine  dumps  in  preparation  for 
installing  a  tactical  minefield.  This  last  example  illustrates 
one  of  the  common  characteristics  of  Type  II  virtual 
dependencies— the  activities  of  unloading  the  truck  and  setting 
up  mine  dumps  is  performed  by  a  nested  team.  While  Type  II 
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virtual  dependencies  are  by  no  means  restricted  to  nested  teams, 
experience  has  shown  that  a  majority  of  Type  ll  Virtual 
dependencies  are  observed  in  nested  teams,  and  observers  should 
be  alert  for  Type  II  Virtual  dependencies  when  nested  teams 
exist  (especially  in  a  dynamic  nested  actual  team  structure). 

While  the  above  discussion  has  dealt  with  defining  the  dependency 
types  which  are  presently  included  in  the  model,  it  has  not  made  clear 
the  point  that  a  given  dependency  occurring  in  a  team  mission  may  have 
two  or  more  parallel  elements  of  different  types.  For  example,  an 
infantry  squad  leader  may  simultaneously  shout  to  his  troops  to  hurry, 
and  raise  and  lower  his  right  fist  over  his  head  in  the  sign  for 
"double  time."  Here,  a  single  dependency  has  two  parallel  elements, 
each  of  which  conveys  the  same  information,  but  of  different  types:  a 
CD  (shout)  and  CN  (hand  signal).  This  is  a  frequent  situation  not  only 
with  respect  to  communicative  dependencies,  but  with  product  types,'  as 

well.  For  example: 

< 

.  the  FADAC  operator  in  an  earlier  example  must  relay  the  firing 
data  from  the  computer  verbally  to  the  RTO  for  further  relay 
to  the  guns.  In  this  case,  the  mediated  procedural  product 
dependency  element  (completion  of  computation  by  the  FADAC)  is 
paralleled  by  a  verbal  communicative  element-calling  out  the 
data  to  the  RTO. 

.  the  ammunition  handler  in  a  mortar  squad  hands  a  prepared  round 
to  the  assistant  gunner  (PP  element)  and  at  the  same  time  says 
"round  up"  (verbal  communicative  element  in  parallel  to  the 
physical  product  element). 

While  these  examples  do  not  exhaust  the  possible  parallel  combinations 
of  two  or  more  element  typos  in  dependencies,  they  are  typical  of  those 
observed  in  building  the  model. 


Dependency  Purposes 

Especially  in  the  case  of  comrnunicat ive  dependencies,  but  also  in 
other  types  of  dependencies,  specifying  only  the  dependency  type  leads 
to  an  incomplete  characterization  of  the  dependency.  Specifying  the 
dependency  typo  does  not,  for  instance,  indicate  how  a  verbal 
comrnunicat ive  dependency  acts  to  facilitate  the  task. performance  of  the 
dependency  recipient (s).  Recording  the  content  of  a  comrnunicat ive 
dependency  element  would  serve  to  completely  clarify  this  ambiguity, 
givmr*iii;it  •*,,e  initiator,  recipient,  and  task  context  were  known.  When 
actually  observing  Yearns  in  the  real-world  performance  environment, 
however,  this  is  impran  l  *  *  nnt  impossible  (imagine  the  resources 

that  would  be  required  to  cap^ft- ^he  exact  contents  of  all  the 
communicative  dependencies  among  membl^T;  of  a  combat  engineer  platoon 
(team!  installing  a  tactical  minefield).  Practically,  a  system  is 
needed  to  characterize  the  general  purposes  of  dependencies  when  the 
purpose  is  not  obvious  from  Mu*  dependency  type  (i.e.,  the  purpose  of 
any  PP  dependency  is  to  make  the  physical  product  available  to  the 
dependency  recipient). 


In  order  to  be  able  to  classify  dependency  purposes  when 
necessary,  the  purpose  categories  described  in  the  following  paragraphs 
have  been  developed.  The  reader  is  cautioned  that  these  categories  by 
no  means  represent  all  possible  dependency  purposes.  The  categories 
presented  here  may  have  some  general  applicability,  but  have  been 
specifically  developed  to  characterize  dependency  purposes  of  the  Array 
teams  that  have  been  observed  in  development  of  the  model.  Work  in 
subsequent  phases  of  this  project  is  planned  specifically  to  expand  and 
make  more  general  the  dependency  purpose  categorization  scheme. 

The  dependency  purpose  categories  currently  defined  and  used  in 
the  context  of  Army  teams  (and  the  abbreviations  that  are  used  to 
represent  the  categories)  are: 

..  Provide  orders,  instructions,  or  directions  to  (an)other 
.  roles(s)  I OID} 


.  Provide  information  to  an(other)  role(s)  regarding: 

-  status  of  mission  progress  or  goal  attainment  (SM) 

-  status  of  individual  task  activity  or  completion  (SIA) 

-  status  of  personnel  (SP) 

-  status  of  supplies  (SS) 

-  status  of  equipment  (SE) 

.  Provide  feedback  or  corrective  information  to  (an)other  role(s) 
(FC) 


j 
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.  Provide  information  about  the  mission  environment  to  (an)other 
role(s)  (IME) 

.  Provide  information  about  OPFOR  to  (an)other  role(s)  (IMO) 

.  Problem-solving  or  didactic  (PS) 

.  Provide  data  to  (an)other  role(s)  (DA) 

Some  examples  to  aid  in  discriminating  between  each  of  the 
egories  are: 


.  (OID)  An  infantry  squad  leader  signals  to  one  of  his  team 
leaders  to.  circle  to  the  left  to  flank  an  enemy  position. 

.  (SM)  The  assistant  squad  leader  of  a  Combat  Engineer  squad 
reports  to  his  squad  leader  that  all  of  the  timber  needed  to 
construct  a  log  crib  obstacle  has  been  cut. 


.  (SIA)  A  member  of  a  TOW  crew  indicates  to  his  section  leader 
that  lie  needs  five  more  minutes  to  finish  filling  sandbags  to 
constructs  parapets  on  either  side  of  the  weapon  position. 

.  (SP)  A  platoon  medic  reports  to  his  platoon  sergeant  that  only 
one  of  three  men  wounded  in  a  fire  fight  is  esrioualy  hurt  and 
needs  to  be  evacuated. 

.  (SS)  A  squad  leader  is  informed  that  members, of  one  of  the  squad 
fire  teams  are  low  on  ammunition. 

.  (SE)  Self-test  of  a  TOW  missle  control  unit  reveals  to  the  TOW 
gunner  that  there  is  not  sufficient  power  left  in  the  batteries 
to  fire  a  missile  (Note:  this  is  a  type  PI  dependency). 

.  (FC)  An  infantry  squad  leader  points  out  that  the  members  of  the 
squad's  Bravo  team  are  walking  toe  close  together  and  directs 
them  to  "spread  out". 

.  (IMF)  The  point  man  on  a  squad  patrol  signals  the  squad  leader 
that  the  squad  is  approaching  a  danger  area. 

.  (IMO)  During  a  frag  order,  a  platoon  leader  indicates  on  a  map 

the  last  reported  position  of  an  enemy  unit. 

* 

.  (PS)  A  squad  member  suggests  a  method  of  bypassing  an 
antivehicular  obstacle  to  his  assistant  squad  leader. 

.  (DA)  After  measuring  the  width  of  a  bridge,  a  Combat  Engineer  . 
calls  out  the  width  to  his  squad  leader. 

As  in  the  case  of  dependency  types,  particular  dependencies  or 
dependency  patterns  may  have  more  than  one  purpose.  For  example,  in  an 
after-action  report  to  his  platoon  leader,  a  squad  leader  may  state 
that  he  is  low  on  ammunition  (SS),  has  four  casualties  (SP),  and  that 
the  enemy  is  just  over  the  next  hill  ( IMO) .  These  items  of  information 
are  all  part  of  the  same  dependency  element,  but  serve  differnt 
purposes.  Dependencies  which  embody  more  than  one  purpose  are 
typically  communicative  dependencies. 

Internal  and  F.xternal  Dependencies 

The  vast  majority  of  dependencies  that'  occur  during  a  team  mission 
have  members  of  the  team  of  interest  as  both  initiators  and  recipients 
of  the  dependency .  In  many  cases,  dependencies  that  are  important  to 
team  missions  involve  persons  who  ate  not  members  of  the  team  as  either 
dependency  recipients  or  initiators.  When  this  occurs,  an  external 
dependency  is  said  to  occur  (when  both  initiators  and  recipients  are 
team  members,  a  dependency  is  called  an  internal  dependency,  although 
the  qualifier  is  not  really  necessary).  External  dependencies  are 


characterized  in  the  same  manner  as  internal  dependencies,  by 
specifying  i ni t iator(s) ,  recipient(s) ,  and  dependency  type(s)  and 
purpose(s).  Note  that  external  dependencies  cannot  occur  in  virtual 
dependency  patterns,  and  that  non-members  of  specific  teams  of  interest 
are  rarely  involved  in  product  dependencies. 

Dependency  Patterns 

Relatively  few  dependencies  occur  in  isolation  from  other  related 
dependencies  or  have  only  a  single  initiator,  recipient,  and  element. 
The  large  majority  of  dependencies  occur  in  related  groups,  or  have 
multiple  initiators,  recipients,  or  elements;  i.e.,  the  dependencies 
occur  in  patterns .  When  dependency  patterns  occur,  it  is  often 
possible  to  describe  the  pattern  in  lieu  of  describing  each  of  the 
dependencies  that  make  up  the  patterns.  Describing  dependency  patterns 
docs  not  result  in  any  significant  toss  of  information,  at  least  in  the 
cases  of  the  teams  and  missions  that  have  been  observed  and  described 
to  date.  In  fact,  there  is  a  significant  information  gain  in 
describing  the  dependency  patterns  that  occur  in  Army  teams  and 
missions  (in  lieu  of  the  individual  dependencies),  since  describing 
patterns  of  dependencies  tends  to  bring  out  complex  relationships 
between  roles  that  are  not  always  apparent  when  each  dependency  is 
described  separately.  Some  dependencies,  of  course,  must  be.  described 
separate  of  patterns  or  in  addition  to  their  inclusion  in  patterns. 

While  the  number  and  variety  of  possible  dependency  patterns  are 
very  large,  several  kinds  of  patterns  have  been  observed  to  occur 
repeatedly  in  the  missions  that  have  been  observed  to  date.  In  fact,  a 
very  few  basic  kinds  of  patterns  have  proven  adequate  to  represent  the 
dependency  pattern  phenomena  that  have  been  observed,  and  have  been 
adopted  as  the  "standard"  patterns  for  inclusioh  in  the  model.  This  is 
not  to  say  that  there  are  not  other  types  of  dependency  patterns  which 
may  exist  and  may  prove  to  be  valuable  additions  to  the  model.  The 
"standard"  patterns  which  have  been  adopted  have  been  sufficiently 
flexible  to  describe  all  the  dependency  patterning  phenomena  that  have 
been  observed  to  date  in  Army  teams,  however. 

The  "standard"  patterns  which  have  been  formalized  are  depicted, 
along  with  the  pattern  symbols  that  hpve  been  developed,  in  Figure  7. 
Description  of  a  pattern  consists  of  entering  the  identification  of 
initiator  and  recipient  roles,  dependency  types  and  purposes,  and 
(occasionally)  other  amplifying  information  around  the  symbol  for  one  ■ 
of  the  "standard"  patterns.  Descriptions  of  each  of  the  "standard" 
dependency  patterns  and  the  characteristics  of  each  pattern  are 
presented  in  the  following  paragraphs.  The  general  form  of  the  symbols 
used  to  represent  dependency  patterns  is  shown  below.  Specific 
examples  of  the  way  this  "basic"  symbol  is  elaborated  to  represent  each 
of  the  "standard"  patterns  are  provided  in  the  discussions  of  each  of 
the  "standard"  patterns. 
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An  r*x;n>n>1f  <»r  .1  simple  dependency,  not  truly  a  pattern  at  all.  Is 
presented  below  to  introduce  the  dependency  pattern  symbols.  Here, 
there  Is  one  dependency  initiator,  one  recipient,  two  dependency  type 
codes  (parallel  types),  and  a  single  purpose.  The  dependency  described 
is  a  verbal  communicative  dependency,  paralleled  by  a  nonverbal 
communicative  dependency,  between  a  squad  leader  (SL)  and  one  of  the 
squad's  team  leaders  (TLA).  The  purpose  of  the  dependency  is  orders, 
instructions,  or  directions.  This  ’’pattern**  is  represented  as:  , 

CD,  CN 

SL  _ fcTLA 

*OID. 

Fanout  dependency  pattern.  This  pattern  involves  a  single 
initiator  role,  multiple  recipient  roles,  and  one  very  similar  (or 
identical)  dependency  element  for  each  recipient  role.  All  the 
elements  need  not  flow  from  the  initiator  to  all  of  the  recipients 
simultaneously,  but  must  occur  reasonably'  close  together  in  time.  The 
classic  example  of  the  fanout  pattern  is  the  delivery  of  the  frag  order 
for  a  mission  by  a  squad  leader  to  a  squad  dispersed  in  an  assembly 
area.  The  squad  leader  moves  individually  to  each  member  of  the  squad 
and  briefs  the  member  independently.  Very  similar  or  identical 
dependency  elements  flow  from  the  initiator  (squad  leader)  to  each 
recipient  (squad  member).  The  elements  are  all  of  the  same  type 
(verbal  communicative)  and  have  the  same  purposes  (a  frag  order  has 
many  purposes). 

The  symbol  for  fanout  patterns  is  as  follows:  the  initiator  role 
code  is  placed  to  the  left  of  the  basic  symbol  line,  and  the  pattern 
symbol  at  the  right  end  of  the  symbol  line  (arrow  in  the  simple 
pattern)  is  replaced  by  a  double  left  caret  («).  Recipient  role  codes 
are  placed  on  top  of  the  basic  symbol  line.  If  any  of  the  recipient 
roles  receive  the  dependency  element  simultaneously,  the  codes  for 
those  roles  are  listed  together  and  set  off  from  other  recipient  roles 
by  parentheses. 

Outward  cluster  dependency  pattern.  In  this  pattern,  there  is  a 
single  initiator  role,  multiple  recipient  rales.,  and  two  or  more 
dependency  elements  of  similar  types  and  purposes-,  but  differing  in 
details  of  the  dependency  element  content  (most  outward  cluster  , 
patterns  involve  communicative  elements).  Two  or  more  of  the 
recipients  may  receive  the  same  dependency  element  content,  but  at 
least  one  recipient  must  receive  an  element , different  in  detail  from 
that  received  by  other  recipients.  An  example  of  this  type  of  pattern 
is  the  assignment  of  sectors  of  fire  to  squad  members  in  defensive 
positions,  by  their  squad  leader.  The  squad  leader  (initiator)  moves 
to  each  foxhole  and  assigns  fire  sectors  to  each  man  (recipient);  each 
fire  sector  is  referenced  to  a  different  set  of  landmarks,  to  provide 
overlapping  sectors  of  fire.  The  general  substance  of  the  dependency 
element  is  the  same  in  each  case  (pertains  to  limits  of  the  sector  of 
fire),  but  differs  in  details  of  the  limits  of  the  sectoL  of  fire 
assigned.  The  elements  of  the  (verbal  communicative)  dependency 
elements  are  similar,  as  are  the  purposes  of  each  of  the  dependencies. 


The  symbol,  lor  an  outward  duster  pattern  is  identical  to  that  of 
the  fanout  pattern  except  for  the  pattern  symbol.  The  pattern  symbol 
for  the  outward  cluster  pattern  is  an  arrowhead  pointing  to  the  right, 
located  at  the  left  end  of  the  basic  symbol  line.  The  position  of 
initiator  and  recipient  role  codes,  and  grouping  of  recipient  role 
codes,  are  the  same  as  for  the  fanout  pattern. 

Inward  cluster  dependency  pattern.  This  dependency  pattern  is 
characterized  by  multiple  initiators,  a  single  recipient,  and  two  or 
more  dependency  elements  that  are  similar  in  type  and  purpose,  but 
differ  in  details  of  dependency  element  content.  Similar  to  outward 
clusters,  many  inward  cluster  patterns  are  composed  of  comnunicative- 
type  dependencies.  An  inward  cluster  pattern  is  .exemplified  by  the 
receipt  of  an  ACE  (Ammunition,  Casualty,  Equipment)  report  by  an 
infantry  squad  team  leader.  After  a  general  call  for  "ACE  report"  each 
member  of  the  fire  team  in  turn  calls  out  to  the  team  leader  the  status 
of  his  ammunition,  whether  or  not  he  is  Injured,  and  whether  he  has  all 
his  equipment  (and  If  lie  does  not,  which  equipment  is  missing).  Again, 
the  general  content  of  dependency  elements  is  the  same,  differing  only 
in  detail;  and  the  type  and  purpose  of  each  of  the  dependency  elements 
that  make  up  the  pattern  is  similar. 

The  symbol  for  inward  cluster  patterns  is  similar  to  that  for 
fanout  or  outward  cluster  patterns,  with  three  exceptions.  First,  the 
pattern  symbol  is  different:  the  symbol  for  an  inward  cluster  pattern 
is  an  arrowhead  pointing  to  the  right,  located  at  the  right  end  of  the 
basic  symbol  line  (the  same  as  the  pattern  symbol  for  a  simple 
"pattern").  Second,  the  recipient  role  code  is  located  to  the  right  of 
the  basic  symbol  line,  adjacent  to  the  pattern  symbol.  Finally,  the 
various  initiator  role  codes  are  placed  on  top  of  the  basic  symbol 
line. 


Propagative  dependency  pattern.  This  pattern  involves  a  single 
first  initiator,  a  series  of  recipients  who  in  turn  become  initiators, 
and  a  single  dependency  element  that  is  "passed  down  the  line";  i.e. , 
the  same  element  moves  from  the  first  initiator  to  one  recipient/ 
initlatorto  the  following  recipient/initiator,  and  so  forth.  Actually, 
there  are  as  many  dependency  elements  as  there  are  Initiator-recipient 
sequences,  but  the  dependency  elements  are  the  same  in  each  case.  One  . 
Initiator  in  a  propogative  pattern  may  provide  the  same  element  to  more 
than  one  recipient,  in  the  fashion  of  a  branching  tree.  An. example  of 
a  progative  dependency  pattern  is  provided  by  an  Infantry  squad  moving 
in,  file  through  thick  jungle,  each  team  member  following  about  ten 
meters  behind  the  man  in  front  of  him.  To  communicate  with  the  rest  of 
the  formation,  ,  the  point  man  gives  a  hand  signal,  which  is  seen  by  the 
next  team  member  in  file,  who  repeats  the  hand  signal.  The  hand  signal 
is  seen  by  the  third  man  in  file,  who  repeats  it  for  the  fourth,  etc. 


The  symbol  for  a  propagative  dependency  pattern  consists  of  the 
basic  symbol  line  and  a  vertical  bar  at  the  left  end  of  the  basic 
symbol  line.  The  first  initiator  role  code  is  placed  at  the  left  of 


the  basic  symbol  line,  and  the  role  codes  for  other  recipient/ 
initiators  in  the  pattern  placed  on  top  of  the  line.  If  the  propaga¬ 
tion  of  the  element  is  other  than  strictly  linear  (i.e.,  one  role  to 
the  next,  to  the  next,  etc),  tlie  branching  or  clustering  of  roles  can 
be  indicated  by  setting  the  particular  roles  in  a  "branch'*  off  in 
parentheses.  Thus,  if  the  first  initiator  in  a  pattern  simultaneously 
transfers  a  dependency  element  to  two  other  roles,  each  of  which  relays 
the  element  to  others  in  a  pass-down-the-line  fashion,  the  grouping 
would  be  symbolized  as:  (2, 3,4, 5, 6)  (7,8,9),  where  the  numbers  are 
role  codies. 


Z.  dependency  pattern.  This  pattern  characterizes  the  successive, 
reciprocal  interchange  of  multiple  dependency  elements  between  two  or 
more  roles.  A  Z  pattern  lias  a  first  initiator,  and  one  or  more 
recipients  who  later  become  initiators  of  dependencies  with  the  first 
initiator  role  as  recipient.  Not  all  of  the  recipients  of  the  first 
element  transferred  necessarily  become  initiators  of  later  elements 
directed  to  the  first  initiator.  The  interchange  of  elements  continues 
until  some  criterion  is  reached,.  Not  all  of  the  dependency  elements  in 
a  Z  pattern  necessarily  have  the  same  type  or  purpose.  A  Z  dependency 
pattern  is  illustrated  by  the  following:  to  properly  set  deflection  on 
a  4.2-in.  mortar,  the  gunner  and  assistant  gunner  must  alternate  in 
making  adjustments  to  the  weapon  mount.  The  gunner  first  sets  the 
desired  elevation  and  deflection  angle  on  the  weapon  sight  mechanism, 
then  adjusts  the  pointing  of  the  weapon  by  traversing  the  mount  until 
his  aiming  stakes  are  lined  up  in  his  sight  telescope.  At  this  point, 
he  instructs  the  assistant  gunner  to  "level"  the  weapon,  which  is  done 
by  adjusting  the  cross-level  knob  pf  the  mount  until  a  bubble  level  is 
centered.  The  assistant  then  calls  "check".  The  process  of 
cross-leveling  throws  the  deflection  angle  of  the  weapon  off  somewhat, 
so  that  tlie  aiming  stakes  no  longer  line  up  exactly  in  the  sights.  The 
gunner  repeats  his  adjustments  to  re-align  the  aiming  stakes,  and  again 
calls  for  "level,”  which  is  once  again  performed  by  the  assistant. 

This  exchange  of  dependency  elements  (interpolated  with  individual 
tasks)  continues  until  the  gunner  is  satisfied.  The  gunner  than  calls 
"gun  up"  to  the  section  leader.  The  successive  interchange  of 
dependencies  between  the  gunner  and  assistant  is  a  Z  pattern.  Uhile 
this  example ■ illustrates  the  simplest  case  of  a  Z  pattern,' more  complex 
Interchanges  are  possible.  For  example,  a  squad  leader's  frag  order  to 
an  assembled  squad  is  frequently  interspersed  with  questions  from  squad 
members  to  the  squad  leader,  which  he  answers  before  going  on  with  the 
•frag  order. 

The  symbol  for  a  Z  pattern  is  substantially  different  from  those 
of  other  patterns.  A  major  difference  is  that  the  role  codes  of  all 
participants  in  the  pattern  are  placed  on  top  of  the  basic  symbol  line. 
The  role  code  of  tlie  first  initiator  is  placed  at  the  extreme  left  of 
the  line,  and  is  separated  from  other  role  codes  by  a  letter  "Z" 


enclosed  between  two  vertical  bars  (the  pattern  symbol).  The  role 
codes  for  other  participants  are  placed  to  the  right  of  the  ~Z"  pattern 
symbol.  The  role  codes  of  any  participants  who  are  only  recipients  of 
dependency  elements  from  the  first  initiator  and  subsequent  other 
initiators,  but  never  initiate  dependencies,  are  set  off  in 
parentheses. 

Virtual  (complex)  dependency  patterns.  Earlier,  it  was  stated 
that  all  virtual  dependencies  are  patterned  groups  of  dependencies. 

The  patterns  of  virtual  dependencies  do  not  generally  correspond  to  any 
of  the  "standard"  patterns  described  above.  Rather,  the  patterns  of 
both  Type  I  and  Type  II  virtual  dependencies  consist  of  a  continuous 
(virtual)  interchange  of  nonobservable  elements  between  all  the  roles 
participating  in  the  virtual  dependency.  This  is  termed  a  "complex" 
pattern,  but  not  further  described.  All  of  the  roles  in  a  virtual 
dependency  pattern  are  simultaneously  and  continuously  dependency 
initiators  and  recipients. 

Virtual  dependencies  are  symbolized  by  placing  the  type  symbol  (Vl 
for  a  Type  I  virtual  dependency  or  V2  for  a  Type  II)  at  the  left  end  of 
the  basic  symbol  line,  with  the  role  codes  for  all  of  the  participants 
on  top  of  the  line.  Purpose  codes  are  not  entered  on  virtual  pattern  ' 
symbols.  Rather,  a  brief  description  of  the  objective  of  the  virtual 
dependency  is  placed  below  the  basic  symbol  line  (l.e.,. "provide 
security,”  or  "unload  truck — establish  mine  dumps"). 

Dependency  patterns  are  a  useful  way  of  representing  related 
groups  of  dependencies,  and  provide  considerable  information  about  the 
patterns  of  interaction  between  the  roles  of  a  team  performing  a 
particular  mission.  Taken  out  of  mission  context,  however,  dependency 
patterns  are  of  little  practical  use,  except  as  a  conceptual  tool  for 
thinking  about  teams,  their  behavior,  and  their  performance. 
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MODEL  SUMMARY  AND  DIRECTIONS  FOR  FUTURE  RESEARCH 


The  model  presented  in  this  report  is  one  of  two  primary  research 
products  of  the  first  year  of  a  three-year  effort  (the  second  product 
is  a  detailed,  procedural  method  for  describing  team  structure  and 
behavior,  based  on  the  concepts  of  the  model).  A  brief  summary  of  the 
model  is  presented  in  Table  3. 

This  project  is  one  of  a  related  group  of  efforts,  with  the 
ultimate  objective  of  evolving  methods  and  techniques  to  improve  the 
performance  of  Army  teams  through  evaluation  of  team  performance  and 
development  of  team  training.  As  mentioned  frequently  in  the 
presentation  of  the  model  as  it  exists,  the  model  is  by  no  means 
final  at  this  time.  Efforts  in  the  subsequent  years  of  the  project 
will  be  directed  toward  refining  and  expanding  the  inode 1  and  the 
description  method,  and  toward  trial  application  of  the  model  concepts 
and  team  descriptions  in  two  critical  areas.  These  areas  are:  (l) 
development  of  a  set  of  techniques,  procedures,  and  criterion 
dimensions  by  which  the  team  performance  of  teams  can  be  measured  and 
evaluated;  and  (2)  evolution  of  a  method  for  identifying  team  training 
requirements  for  teams  and  team  types,  based  on  team  performance 
descriptions.  In  addition,  methods  and  guidelines  for  selecting  team 
training1 techniques  and  procedures  for  team  types  will  be  explored; 

Planned  developments  to  this  model  in  subsequent  phases  of  the 
project  include: 

.  Expanding  and  refining  of  the  dependency  purpose  scheme  and 
incorporating  related  research  findings  on  team  functions  to 
make  the  dependency  purpose  categorization  scheme  more  complete 
and  useful; 

*  .  Clarifying  the  relationships  between  the  various  descriptive 

characteristics  of  team  types  and  missions; 

.  Modifying  the  concepts  of  the  model,  or  adding  new  concepts,  to 
be  able  to  adequately  describe  team  phenomena. 

.  Developing  an  initial  understanding  of.  the  ways  in  which  team 
structure,  team  missions,  and  constraints  may  influence  team 
behavior,  and  incorporating  any  such  relationships  into  the 
model. 

Adventitious  developments  of  the  model  may  also  occur.  It 
may  be  that,  in  observing  and  describing  teams  to  accomplish  the 
objectives  of  the  subsequent  years  of  this  work,  valuable  insights  may 
be  made  that  can  improve  the  descriptive  potency  of  the  model  or 
materially  add  to  model  completeness.  Any  such  insights  will  be  fully 
developed  and  added  to  the  model,  along  with  new  concepts  and 
variations  on  present  model  concepts  that  will  contribute  to  the 
generality  and  usefulness  of  this  model  as  a  vehicle  for  studying 
teams. 
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MODEL  SUMMARY 


TEAM  DEFINITION: 

Two  or  more  person;  who  are — 

Involved  in  a  common  mission,  working  to  fulfill  a  common 
objective;  where— • 

Responsibility  for  performing  mission  tasks  is  divided  among 
team  members;  with — 

Dependencies  among  team  members. 

(teams  may  or  may  not  have  a  formal  organizational 
structure). 

MISSION  DEFINITION: 

1.  Closed-ended,  bounded  set  of  activities;  with— 

2.  A  definite,  purposeful,  and  achievable  goal;  that — 

3.  Requires  two  or  more  individuals,  with  distributed 
responsibilities  for  achieving  mission  objective,  to  perform 
mission  in  a  reasonable  time  period. 

TEAM  ORGANIZATION  AND  STRUCTURE: 

Nominal  Team  Structure:  described  by: 

1.  Name  of  team; 

2.  Number  of  members; 

3.  Position  descriptions  (e.g.,  MOS,  equipment); 

4.  Hierarchial  relationships  among  positions  (including  nominal 
nested  teams); 

5.  Team  type  descriptors  (missions  variety;  degree  of 
procedural izat ion  of  missions,  equipment  dominance, 
environmental  reactivity). 

Actual  Team  Structure:  described  by: 

Team  type  name  and  designation  of  particular  team; 

Mission  name; 

Number  and  characteristics  (MOS,  equipment)  of  roles; 
Description  of  responsibilities  of  each  role; 

Description  of  hierarchial  relationship#  among  team  members, 
including  nested  teams; 

Mission  descriptors  (goal,  degree  of  proceduralization, 
equipment  dominance,  mission  environment). 

TEAM  BEHAVIOR:  described  by: 

1.  Individual  activities  or  tasks  (associated  with  roles);  and 

2.  Time  or  phasing  relationships  between  individual  tasks  and 
dependencies,  and; 


1. 

2. 

3. 

4. 
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MODEL  SUMMARY  (con't) 

Dependencies:  for  each  dependency  (or  pattern)-- 
Initiator  role(s) 

Recipient  role(s) 

Dependency  types  (verbal  communicative,  nonverbal 
communicative,  physical  product,  mediated  procedural 
product,  nonmediated  procedural  product.  Type  £  virtual. 
Type  IT  virtual) 

Dependency  purposes  (provide  information  about:  orders, 
instructions,  directions,  status  of  individual  task 
activity,  status  of  mission  progress,  status  of  personnel, 
supplies,  or  equipment,  provide  feedback  or  corrective 
action,  information  about  mission  environment  or  OPFOR, 
problem-solving,  data) 

Dependency  patterns — 

.  Fanout:  single  initiator,  multiple  recipients,  very 
similar  element  (same  type  and  purpose) 

.  Outward  cluster:  single  initiator,  multiple  recipients, 
somewhat  similar  elements  (similar  types,  purposes,  but 
different  content,  and  provided  at  different  times) 

.  Inward  cluster:  multiple  initiators',  single  recipient, 
somewhat  similar  elements  (similar  types,  purposes,  but 
different  details  of  content,  and  provided  at  different 
times) 

.  Propagative:  single  element,  passed  from  one  recipient/ 
initiator  to  the  next,  and  so  forth;  may  "branch*' 

.  Z:  successive  interchange  of  elements  between  _>  2  team 
members,  one  member  initiates  entire  pattern,  other(s) 
respond  (as  in  quest ion-and-answer)  , 

.  Virtual  (Type  l):  continuous,  mutual  interchange  of 
dependency  elements  between  participants,  continues  over 
time 

.  Virtual  (Type  II):  nonspecified  division  (ad  hoc)  of  a 
.  set  of  tasks  between  several  team  members  with  no 
consistency  in  task  allocation  over  repetitions  of  the 
event ,  or  time . 


•  - 
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SECTION  2 


TEAM  AND  TEAM  MISSION  DESCRIPTION  METHOD 

Introduction 


The  first  section  of  this  report  described  the  model  of  team 
organization  and  behavior/per formance .  The  purpose  of  this  section  of 
the  report  is  to  present  the  Description  Method  that  accompanies  the 
models  It  Is  no  accident  that  the  model  of  team  organization  and 
behavior /performance  was  described  first.  The  Description  Method, 
presented  in  this  report,  was  derived  directly  from  the  concepts 
contained  in  the  model.  The  model  identifies  those  variables  or 
dimensions  of  team  organization  and  team  behavior  that  are  considered 
important  to  successful  team  performance.  The  Description  Method 
provides  a  mechanism  for  identifying  and  recording  those  important 
variables  or  dimensions  in  a  systematic  way,  to  generate  team  descrip¬ 
tions  (team  organization  descriptions)  and  team  mission  descriptions 
(descriptions  of  team  mission  behaviors). 

Before  discussing  the  Description  Method,  it  is  necessary  to 
understand  how  the  descriptions  produced  by  the  Description  Method  will 
be  used.  It  is  anticipated  that  the  descriptions  resulting  from  the 
application  of  the  Description  Method  will  have  many  useful  purposes. 
These  are : 

1.  The  resulting  descriptions  can  serve  as  a  database  from 
which  team  training  requirements  can  be  identified.  From 
the  identified  requirements,  team  training  programs  and 
materials  can  be  developed. 

2.  The  resulting  descriptions  can  also  serve  as  a  database 
from  which  team  performance  measures  can  be  derived.  These 
measures  can  be  used  to  assess  or  evaluate  team  perform¬ 
ance,  to  diagnose  team  performance  deficiencies,  and  to 
prescribe  team  training. 

3.  The  resulting  descriptions  will  be  an  invaluable  research 
tool.  For  example,  the  descriptions  can  be  used  to 
discover  how  teamwork  developed,  and  to  identify  critical 
differences  (behavior)  between  successful  and  unsuccessful 
teams. 


At  this  writing,  the  procedures  to  analyze  the  resulting  descrip¬ 
tions  to  identify  team  training  requirements  and  derive  measures  of 
team  performance  have  not  been  developed.  The  development  of  these 
analysis  techniques  is  scheduled  for  tlie  second  and  third  years  of  tie 
project. 

This  section  of  the  report  discusses  the  step-by-step  procedure i 
required  to  apply  the  Description  Method,  and  produce  team  organizat  .on 
descriptions  and  team  mission  behavior  descriptions.  It  does  not 
present  any  procedures  for  how  to  use  or  analyze  the  resulting 
descriptions. 


Overview  of  the  Description  Method 


The  Description  Method  is  composed. of  four  major  steps.  These 

are: 

1.  Select  the  team  (or  team  type)  to  be  described  (Step  1). 

2.  Describe  the  team  type  organization  (Step  2);  i.e., 
describe  the  nominal  team  structure. 

3.  Select  the  mission  to  be  described  (Step  3). 

4.  Describe  each  of  the  selected  missions  (Step  4).  This 
includes  describing  the  actual  team  structure  used  to 
accomplish  the  mission,  and  a  description  of  the  team 
mission  behaviors. 

Each  of  these  steps  are  described  in  detail  in  the  following  sections. 

However,  before  fully  discussing  each  stdp,  it  is  beneficial  to  clarify. 

some  important  points  about  the  Description  Method. 

The  Description  Method  is  composed  of  two  Ingredients.  These 

are: 

1.  A  set  of  recording  forms.  These  recording  forms  contain 
the  Information  necessary  to  describe  the  team  or  team  type 
organizations  and  the  team  mission  behaviors. 

2.  A  set  of  instructions  or  procedures  which  specifies  how  the 
information  contained  on  the  recording  forms  is  to  be 
generated  (or  gathered)  and  recorded. 

The  step-by  step  procedures  then  describe  how  and  when  the  recording 

forms  are  completed. 
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To  provide  an  orientation,  the  next  two  sections  briefly  discuss 
tl>e  recording  forms  and  tlie  procedures  for  gathering  the  required  data. 
This  orientation  is  provided  for  several  reasons: 

1.  It  is  beneficial  to  realize  the  kind  of  data  or  information 
that  is  collected  about  teams  and  team  missions  before 
discussing  each  of  the  four  major  steps. 

2.  It  is  important  for  the  reader  to  "see"  how  the  required 
data  is  related  to  the  ultimate  uses  of  the  generated 
descriptions  (i.e.,  the  reader  should  realize  that  the  data 
used  to  describe  team  organization  and  team  behavior  is  the 
kind  of  data  that  will  be  useful  in  Identifying  team 
training  requirements  and  measures  of  team  performance. 

3.  It  is  beneficial  to  realize  that  the  required  data  is 
indeed  related  to  the  model  of  team  organization  and  ' 
behavior. 

4.  It  is  necessary  to  discuss,  in  general,  how  the  users  of 
the  Description  Method  will  be  required  to  collect  the 
necessary  data. 


Brief  Orientation  to  the  Recording  Forms 

The  Description  Method  contains  eight  recording  forms.  A  list  of 
the  recording  forms  is  provided  in  Table  1.  The  titles  of  the 
recording  forms  provide  a  hint  to  the  kind  of  data  and/or  information 
that  is  used  to  describe  team  organizations  and  team  behaviors.  To 
gain  a  further  appreciation  for  the  kind  of  data  and/or  Information 
that  must  be  generated  and  recorded  when  applying  the  Description 
Method,  Table  2  is  offered.  This  table  presents  a  list  qf  the  data 
items  that  are  contained  on  the  various  recording  forms,  collectively. 
It  should  be  no  surprise  that  the  data  items  can  be  organized  into 
three  major  groups: 

l.  Those  concerning  the  organizational  structure  of  the 
nominal  team. 


2.  Data  items  concerning  the  organizational  structure 
actual  team,  and 


of  the 


3.  Data  (terns  concerning  the  team  activities  associated  with 
performing  a  mission  (mission  specific  data  items). 

It  should  be  no  surprise  that  data  items  are  similar  to  the  diaensions 
and  factors  specified  in  the  model  of  team  organization  and 
behavior/performance. 
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Table  4 


List  of  Recording  Forms 

FORM  1  -  Team  Mission  Listing 

FORM  2  -  ffominal  Team  Structure 

FORM  2A  -  fixninal  Thant  Organizational  Chart 

FORM  3  -  General  Mission  Information 

FORM  3A  -  Mission  Situational  Map 

FORM  4  -  Actual  Team  Structure 

FORM  4A  -  Actual  Team  Structure — Nested  Team  Description 
FORM  5  -  Mlssion/Tean  Activity  Description 


Table  2 


List  of  Data  Items 


Position  Titles  of  Nominal  Team  Members 
Nutter  of  Nominal  Team  Maters 
Function  of  Nominal  Team  Matters 
Equipment  Used  by  Nominal  Team 
Assignment  of  Equipment  to  Nominal  Than 
Maters 

Existence  of  Nominal  Nested  Teams 
Size  of  Nominal  Nested  Teams 
Function  of  Nominal  Nested  Than 


Position  Title  of  Actual  Thant  Heaters 
Nutter  of  Actual  Team  Hesters 
Fire t Ion  of  Actual  Team  Matters 
Equipment  Used  by  Actual  Tea*  Maters 
Assignment  of  Equipment  to  Actual  Thai 
Miters 

Existence  of  Actual  Nested  Thaos 
Size  of  Actual  Nested  Team 
Fine t ion  of  Actual  Nested  Thaos . 


List  of  Missions  Performed  by  Tfeita 
Mission  Goal 

General  Mission  Procedures 
Non-Organ Ic  Support  Required  for  Mission 
Mission  Environmental  Conditions 
AK3FP  Standards 

Sequence  of  Mission  Activities 
Existence  of  External  Dependencies 
Existence  of  Internal  Dependencies 
Dependency  Initiators  and  Recipients 
Uhpeitlenry  Elements 
Heivniency  Hittems 
Dependency  Type 
Dependency  Purpose 


Brief  Orientation  to  How  the  Data  is  Generated 

Tlte  data  generation  procedures  specified  in  the  Description  Method 
were  based  upon  a  validation  study  of  the  Description  Method.  The 
validation  study  was  partially  designed  to  determine  which  sources 
would  be  the  most  appropriate  to  use  to  generate  the  required  data. 
Three  sources  were  explored:  military  documentation,  Subject  Matter 
Expert  (SHE)  interviews,  and  direct  observation.  The  procedures 
suggested  in  this  report  are  those  which  the  authors  believe  will 
produce  the  most  reliable,  usable,  and  accurate  team  organization 
descriptions  and  team  mission  descriptions  (team  behavior  descrip¬ 
tions). 

It  was  discovered  during  the  validation  effort  that  no  one  source 
was  the  "best"  to  collect  all  the  data  items.  Some  sources  were 
"better"  for  some  data  items  than  other  sources.  Each  source  had  its 
unique  properties  with  respect  to  tliu  required  data  items.  As  a 
result,  the  Description  Method  presented  uses  for  all  three  sources 
(military  documentation,  SME  interviews,  and  direct  observation)  at 
various  times.  In  general,  information  concerning  the  nominal  team 
structure  is  generated  by  reading  military  documentation  and  interview¬ 
ing  SMEs.  Actual  team  structure  information  is  generated  via  direct 
observation  and  interviews  with  actual  team  members.  The  mission 
specific  data  is  also  generated  by  direct  observations  of  actual  teams 
performing  the  missions  of  interest,  supplemented  by  interviews  with 
actual  team  members.  The  procedures  described  herein  clearly  Indicate 
when  and  how  the  various  sources  are  to  be  used. 

It  should  bo  clearly  understood  that  the  data  generation  proce¬ 
dures  specified  in  this  report  are  those  the  authors  believe  to  the 
"best";  they  represent  an  ideal.  The  authors  recognize  that  frequently 
it  might  not  be  possible  to  obtain  the  required  information  from  the 
suggested  sources  and  that  an  alternate  source  might  be  used.  Indeed, 
the  required  data  Items  can,  to  varying  degrees,  be  gathered  from  any 
of  the  three  sources.  However,  there  are  some  risks  involved  when 
using  different  sources  for  specific  data  items  than  those  recommended 
in  this  report.  For  example,  ,SMEs  intend  to  vary  in  their  perception 
of  mission  activities  and  team  behaviors.  Thud,  if  SME  interviews  are 
used  to  generate  specific  mission  information,  the  resulting  descrip¬ 
tions  may  not  be  as  reliable  or  as  accurate  as  using  direct  observation 
(the  recommended  source). 

If  the  recommended  sources  cannot  be  used,  the  reader  is 
encouraged  to  consider  the  alternative  sources. I  The  user  is  also 


*The  current  Description  Method  does  not,  however,  provide  guidance 
on  how  alternative  sources  can  be  used  to  generate  the  required  data. 


encouraged,  however,  Co  consider  the  risks  involved  in  using  nan- 
recommended  sources. ^ 


Cautionary  Notes 

It  should  be  clear  from  the  previous  sections  that  the  Description 
Method  produces  two  kinds  of  descriptions.  A  team  organization 
description  (i.e.,  a  description  of  the  nominal  team  and  actual  team 
organizational  structures)  and  a  team  behavior  description  (i.e.,  a 
description  of  the  team  behaviors  required  to  complete  a  specific 
mission).  Only  one  nominal  team  organization  description  is  required 
for  each  team  type  of  interest  (for  each  team  type  that  is  to  be 
described),  since  tlie  nominal  team  structure  Is  invariant  with  respect 
to  the  missions  performed  by  the  team  type.  On  the  other  hand,  one  . 
description  is  needed  for  each  mission  that  is  to  be  described. 
Furthermore,  an  actual  team  organization  description  is  required  for 
each  mission  that  is  described,  since  the  actual  teas  structure  may 
vary  from  mission  to  mission  (due  to  understrength  or  overstrength 
circumstances).  Thus,  If  ten  missions  arc  described  for  a  given  team 
type,  the  Description  Method  would  generate:  one  nominal  team 
organization  description,  ten  actual  team  organization  descriptions, 
and  ten  mission  behavior  descriptions. 

The  step-by-step  procedures  discussed  in  this  report  explain  how  a 
single  nominal  team  organization  description,  a  single  actual  team 
organization  description,  and  a  single  mission  description  is  generated 
or  produced.  However,  it  should  be  realized  that  the  same  procedures 
can  be  used  to  generate  all  the  necessary  mission  descriptions  and 
actual  team  structure  descriptions  for  a  given  team  type. 

It  Is  also  necessary  to  point  out  that  the  current  Description 
Method  docs  not  contain  procedures  for  summarizing  data  or  Information 
across  missions  or  actual  team  organizations.  That  is,  if  for  a,  given 
team  type  ten  mission  descriptions  (and  thus  the  actual  team  organiza¬ 
tion  descriptions)  are  generated,  the  current  method  does  not  provide 
any,  guidance  concerning  how  the  information  obtained  can  be  summarized 
across  the  ten  mission  descriptions  and  the  ten  team  structure  descrip¬ 
tions.  it  is  anticipated  that  such  procedures  will  be  developed  lit  the 
second  and  third  years  of  the  project. 

It  should  also  he  recalled  (from  previous  discussions)  that  the 
current  method  does  not  provide  guidance  on  how  to  analyze. the  result¬ 
ing  descriptions  to  identify  team  training  requirements  and  measures  of 
team  performance. 


^To  obtain  an  appreciation  of  the  possible  risks  Involved  in  using 
non-recommended  sources,  the  results  of  the  validation  of  the 
Description  Method  should  be  read. 


SELECT  THE  TEAM  TYPE  TO  BE  DESCRIBED  (STEP  1) 


The  first  step  in  applying  the  Description  Method  is  to  select 
(identify)  the  team  type  to  be  described.  It  should  be  recalled  that 
the  descriptions  generated  or  produced  by  applying  the  method  can  be 
used  for  three  purposes.  Thus,  a  team  type  should  be  selected  if  there 
is  an  interest  in  any  of  the  following: 

1.  Identifying  team  training  requirements  and  constructing 
team  training  programs  for  the  team  type. 

2.  Deriving  measures  of  team  performance  for  the  team  type  so 
that  the  teams  who  are  members  of  the  team  type  can  be 
evaluated  or  assessed. 

3.  Studying  the  development  of  teamwork  in  the  team  type. 

Step  1  requires  performing  two  substeps.  These  are: 

1.  Precisely  labeling  the  selected  team  type. 

2.  Verifying  that  the  selected  team  type  is  indeed  a  team. 


Labeling  Team  Types 

The  Description  Method  requires  a  precise  definition  (label)  of 
the  team  type.  This  label  must  include  the  general  name  of  the  team, 
the  echelon  of  interest,  and  any  modifiers  to  name.  For  example,  the 
following  labels  are  satisfactory:  Infantry  squads,  light,  mechanized; 
Infantry  squads,  regular,  airborne;  Infantry ' squads,  light,  air 
assault;  Infantry  platoons,  Light,  mechanized;  Fire  Direction  Centers, 
mortar  squads;  etc.  Each  of  the  above  labels  represent  a  different 
team  type.  The  following  labels  arc , not  satisfactory:  Infantry 
squads,  Infantry  platoons,  mortar  squads,  etc.  These  labels  are  not 
precise  enough  and,  if  used,  cause  problems  and  confusion  in  the 
remaining  steps  of  the  Description  Method.  The  labels  must  clearly 
communicate  any  variation  in  the  general  team  type  name.  This  kind  of 
precision  is  needed  for  several  reasons: 

1.  The  missions  performed  by  the  various  variations  of  the 
team  may  be  different;  e.g..  Infantry,  (light,  mechanized) 
squads  may  perform  a  different  set  of  missions  than  air 
assault  squads. 3 

2.  The  nominal  team  structure  of  apparently  similar  team  types 
may  be  different. 


3lt  is  recognized  that  there  may  be  many  common  missions  between 
apparently  similar  team  types,  but  it  should  also  be  understood  that 
there  may  be  some  unique  missions.  ^ 
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If  apparently  dl  1 1  o  rent  team  types  do  not  |>ertorin  different  missions  or 
are  not  organized  differently,  then  it  is  satisfactory  to  use  the  same 
label  for  both  team  types.  However,  this  is  the  only  condition  when 
the  same  label  should  be  used  to  describe  two  team  types. 

Verifying  the  Selected  Team  Type 

After  the  team  type  has  been  selected  and  precisely  labeled.  It  is 
necessary  to  confirm  that  the  selected  team  type  qualifies  as  a  team. 

It  should  be  recalled  that  the  model  presents  a  definition  of  a  team. 
The  selected  team  type  would  qualify  as  a  team  providing  the  following 
criteria  are  met: 

1.  The  team  type  selected  is  composed  of  more  than  two 

'  individuals.  For  practical  reasons;  the  selected  team  type 
shouLd  not  be  larger  than  30  individuals.^ 

2.  All  the  members  of  the  team  work  together  to  successfully 
attain  the  assigned  team  missions;  i.e.,  each  team  member 
must  work,  toward  the  accomplishment  of  the  same  objective 
within  the  mission  context. 

3.  Each  team  member  Is  assigned  responsibilities  (Individual 
tasks)  within  each  mission. 

4.  There  are  dependencies  (as  defined  by  the  model)  between 
the  various  team  members. 

If  the  selected  team  type  does  not  meet  each  of  the  above  criteria, 
then  another  team  type  must  be  selected,  labeled,  and  the  process 
repeated. 

Comments 

To  precisely  label,  the  team  type  and  to  verify  that  the  team  type 
meets  the  definition  of  a  team  requires  "knowing”  something  about  the 
team  type;  i.e.,  in  order  to  satisfactorily  label  the  team  type,  it  la 
important  to  know  that  there  may  be  variations  among  the  teams  which 
are  generally  considered  the  same  team  type,,  and  in  order  to  verify 
that  the  selected  team  is  indeed  a  team  requires  some  familiarity 
with  the  missions  performed  by  the  team.  Thus,  this  first  step  of  the 
Description  Method  assumes  the  user  of  the  method  has  some  degree  of 
familarity  with  the  team  type  of  interest.  If  the  user  does  not 


^If  the  other  criteria  are  met,  but  the  team  type  selected  is  larger 
than  30  team  members,  then  consider  reorganizing  the  larger  team  Into 
smaller  team  types.  The  Description  Method  becomes  difficult  to 
apply  when  the  team  type  is  large. 


possess  this  sort  of  familiarity  with  the  selected  team  type,  the 
following  is  recommended: 

1.  Discuss  the  possible  variations  of  the  selected  team  with 
an  SME  or  a  team  member  incumbent.  A  good  place  to  go  is 
to  the  appropriate  branch  school  for  the  suspected  team 
type. 

2.  Obtain  any  available  documentation  which  might  clarify  the 
variations. 

3.  Obtain  and  review  any  ARTEP  manuals  for  those  teams  which 
appear  to  be  similar  and  check  the  list  of  missions.  Do 
different  variations  of  the  team  perform  different 
missions? 

4.  Obtain  TO&E  reports  for  those  teams  which  appear  similar, 
and  determine  if  the  teams  are  comprised  of  the  same 
position  titles. 
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DESCRIBE  THE  TEAM  TYPE  (STEP  2) 


The  second  step  of  the  Description  Method  is  to  generate  a  list  of 
missions  performed  by  the  selected  team  type  and  to  document  the 
nominal  team  structure  of  the  two.  Three  recording  forms  are  completed 
during  Step  2.  Form  1  is  provided  to  document  the  missions  performed 
by  the  selected  team  type.  Form  2  and  Form  2A  are. provided  for 
recording  the  nominal  team  structure  and  the  nominal  team  organization 
chart,  respectively.  The  instructions  for  generating  the  required 
information  and  for  correctly  recording  the  information  on  the 
recording  forms  are  provided  below. 

Before  presenting  the  steps  involved  in  completing  the  forms,  it 
■ay  be  beneficial  to  discuss  what  idata  are  collected  in  this  step  and 
why.  The  list  of  missions  performed  by  the  team  type  of  interest  is 
recorded  for  the  following  reasons: 

1.  The  list  of  mission  titles  is  used  later  in  the  method, 
when  the  missions  to  be  discribed  are  selected. 

2.  The  list  of  mission  titles  provides  an  excellent,  vehicle 
for  understanding  what  it  is  the  team  type  really  does. 

That  is,  the  reader  of  the  descriptions  generated  can 
survey  or  review  the  mission  listing  and  quickly  capture 
the  kinds  of  things  the  team  type  does. 

The  nominal  team  structure  information  recorded  on  Forms  2  and  2A  is  as 
follows: 

1.  The  position  title  of  each  team  member. 

2.  The  MOS  code  for  each  position  title. 

3.  The  number  of  individuals  holding  each  position  title  (thus 
the  size  of  the  nominal  team). 

4.  The  likely  rank  of  each  position  title. 

5.  The  equipment  typically  used  by  each  position  title. 

6.  A  nominal  team  organizational  chart,  which  shows  the 
hlerarchlal  relationship  between  each  position  title 
(and/or  team  member)  and  each  nominal  nestdd  team  (if 
any). 


This  informal ion  is  recorded  and  becomes  part  of  the  generated 
descriptions  for  several  reasons.  These  are: 

1.  The  reader  of  the  description  can  use  the  recorded 
information  to  obtain  an  immediate  picture  of  the  nominal 
team  (particularly  the  nominal  team  organizational  chart). 

2.  It  should  be  recalled  that  the  ndminal  structure  is 
invariant  with  respect  to  the  missions  performed  by  the 
team.  In  Step  4  of  the  Description  Method,  the  actual  team 
structure  is  documented.  It  should  be  recalled  that  the 
actual  team  structure  may  vary  from  mission  to  mission.  It 
is  useful  (for  both  team  training  purposes  and  for  team 
performance  measurement  purposes)  to  compare  the  nominal 
team  structure  with  the  actual  team  structure* 


Team Mission  Listing  (Form  1) 

x 

The  team  mission  listing  form  is  composed  of  two  components. 

These  are: 

1.  A  photocopy  of  the  mission  titles  performed  by  the  team 
type  as  found  in  the  appropriate  ARTEP  manual,  and 

2.  Form  1,  which  is  provided  to  update  the  list  of  ARTEP 
missions.  Form'  l  is  completed  by  requesting  an  SME  to 
review  the  list  of  ARTEP  missions  and  to  delete  or  add 
missions. 

The  instructions  for  developing  a  list  of  missions  and  completing 

Form  1  are  as  follows: 

1.  Obtain  the  appropriate  ARTEP  manual  for  the  team  type  of 
interest.  Locate  in  the  ARTEP  manual,  the  list  of  missions 
performed  by  the  team  type.  Be  sure  to  select  the  list 
which  reflects  the  appropriate  echelon  (squad,  platoon, 
section).  Photocopy  the  list  and  attach  it  to  Form  1. 

2.  Make  arrangements  to  have  an  SME  review  the  list  for 
accuracy;  i.c.,  to  identify  missions  which  may  no  longer  be 
performed  by  tlie  team  type  and /or  missions  which  may  have 
been  recently  added  to  the  list.  SMEs  are  the  branch 
schools  can  be  used  for  this  purpose. ^  if  you  are  an 

SME,  then  arrangements  for  another  SME  need  not  be  made. 


^For  example,  if  the  selected  team  is  Combat  Engineer  squads, 
mechanized,  then  the  Directorate  of  Training  Development  at  Fort 
Belvolr  would  be  a  reasonable  place  to  locate  SMEs. 


MISSION  LISTING  .  FORM  1 


ARTEP  Mission  Listing 


Complete  Blocks  l,  2,  and  3  of  Form  1. 


a.  In  Block  L  enter  the  label  of  the  teas  type  selected 
(be  precise). 

b.  In  Block  2  enter  your  name  and  title. 

c.  In  Block  3  enter  the  date  the  form  was  prepared; 
enter  month,  day,  and  year  (each  as  a  two  digit 
code— 05/19/84). 

Your  may  also  find  it  convenient  to  record  the  title  of  the 
ARTEP  manual  used  at  the  bottom  of  Form  1. 

Have  the  SHE  review  the  photocopy  of  the  ARTEP  missions, 
and  then  ask: 

a.  Does  the  team  perform  any  mission  not  listed? 

If  the  answer  is  "Yes,”  then  on  Form  1  list  each  of 
the  "new"  missions  (or  the  to  be  added  missions)  in 
Block  4.  Also  place  an.  "X"  in  the  add  column  of 
•  Block  5. 

It  should  be  noted  that  the  ARTEP  manual  usually 
contains  some  sort  of  hierarchy  categorization 
scheme.  For  example,  for  Combat  Engineers,  the 
missions  are  divided  into  Major  Mission  Operations. 
Within  each  Major  Mission  Operation  are  a  list  of 
missions.  In  other  ARTEP  manuals,  the  term  "Major 
Mission  Operations"  may  not  be  used,  but  there  will 
be  a  major  heading  of  some  sort.'  It  seems  desirable 
to  record  the  "added"  missions  by  their  major 
headings.  In  this  way,  all  the  “added"  missions 
within  the  major  heading  will  be  located  in  the  same 
place  on  Form  1.  . 

Complete  Blocks  6,  7,  and  8  for  each  added  mission. 
In  Block  6  enter  the  SHE 's  name  and  title.  In  Block 
7  enter  the  date  the  "added"  mission  was  identified. 
In  Block  8  enter  any  other  information  about  the 
mission  that  might  be  useful  (e.g.,  why  the  mission 
was  added). 

b.  Arc  there  any  missions  on  the  list  which  should  be 
deleted  from  the  list;  missions  which  the  team  no 
longer  perform? 


If  “Yes,”  then  on  Form  1  enter  the  title  of  each 
mission  to  he.  deleted.  Be  sure  to  use  the  same 
mission  title  as  indicated  on  the  photcopy  or  the 
ARTEP  mission  list.  Again,  the  deleted  missions 
should  be  organized  by  major  heading.  After 
recording  each  deleted  mission,  complete  Blocks  5, 

6,  7,  and  8.  In  Block  5  place  an  "X”  in  the  second 
column;  the  column  labeled  “DEL."  Complete  Blocks 
6,  7,  and  8  according  to  the  instructions  provided 
above.  In  Block  8  enter  the  reason  why  the  mission 
has  been  or  should  be  deleted  from  the  ARTEP  mission 
list. 

You  may  find  it  convenient  to  place  a  line  through 
the  deleted  missions  on  the  phototcopy.  This  will 
highlight  the  fact  that  the  mission  Is  not  performed 
by  the  team  type. 

c.  lias  the  content  of  any  of  the  missions  or  mission 
titles  changed? 

If  “Yes,”  enter  the  mission  title  (the  one  appearing 
on  the  photocopy  of  the  ARTEP  mission  list)  in  Block 
4  (and  record  the  “new“  mission  title  in  Block  8). 

If  the  title  has  remained  the  same,  but  the  content 
or  intent  of  the  mission  has  changed,  then  record 
the  "new"  intent  in  column  or  Block  8. 


Complete  Blocks  5,  6,  and  7  in  the  usual  manner. 

An  example  of  a  completed  Form  1  is  provided  in  Appendix  B.  It 
should  be  noted  that  the  missions  which  were  added,  deleted,  or  changed 
are  organized  by  each  Major  Mission  Operation. 

As  a  precaution  or  an  extra  check,  it  is  desirable  to  repeat  the 
interview  with  another  SME  or  team  member  incumbent.  The  information 
gathered  from  the  second  SME  can  be  recorded  on  the  same  Form  1.  This 
is  not  a  necessity,  but  it  can  increase  the  accuracy  of  the  Information! 
recorded  on  Form  1. 

Once  you  have  completed  Form  1  and  attached  the  ARTEP  mission 
list,  you  should  have  an  accurate  list  of  all  the  missions  performed  by 
the  selected  team  type. 


Nominal  Team  Structure  (Form  2) 


'  Form  2  provides  a  mechanism  to  record  the  nominal  team  structure 
of  the  selected  team  type.  It  should  be  recalled  that  the  nominal  team 
structure  is  the  structure  of  the  team  type  When  it  is  at  full  strength 
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NOMINAL  TEAM  STRUCTURE  form  2 


(when  It  is  not  under-  or  overstrength).  It  Is  the  structure 
represented  by  the  TO&K.  Form  2,  when  completed,  will  provide  an 
immediate  picture  of  the  nominal  team  structure.  It  will  be  useful  to 
compare  Form  2  with  actuaL  team  structure  (which  is  completed  later  in 
the  method).  Form  2  is  primarily  designed  to  record  the  following 
information: 

1.  The  position  title  and  Military  Occupational  Specialty 
(MOS)  code  of  each  member  of  the  nominal  structure  of  the 
team  type. 

2.  The  equipment  used  and  assigned  to  the  team  type. 

Valuable  sources  to  use  when  completing  Form  2  are  military 
documents;  e.g., 

1.  The  Table  of  Organization  and  Equipment  (TO&E). 

2.  The  ARTE P  manual  for  the  selected  team  type. 

3.  Appropirate  field  manuals  and  technical  manuals. 

These  documents  usually  contain  the  required  information,  but  the 
reader  might  have  to  rely  on  personal  experience  or  consult  with  an  SME 
to  complete  Form  2. 

The  instructions  for  completing  Form  2  are  as  follows: 

1.  In  Block  l  enter  a  copy  of  the  label  of  the  team  type 
entered  in  Block  1  of  Form  1. 

2.  In  Block  2  enter  the  sources  that  are  used  to  prepare  Form 
2.  For  clarity,  the  following  should  be  entered  from  each 
source. 

a.  The  exact  title  of  the  document(s). 

b.  '  Any  reference , number  the  document(s)  might  have. 

c.  The  date  of  the  document(s). 

.  d.  .  The  specific  page  number  of  the  document (s)  where 
the  information  recorded  on  the  form,  can  be 
obtained. 

3.  In  Block  3  enter  your  name  and  title. 

4.  In  Block  4  enter  tlx*  date  Jie  form  was  prepared.  Enter  the 
month,  day,  and  year  (each  as  a  two-digit  number). 
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5.  Block  5  can  only  be  completed  when  It  Is  determined  how 
many  pages  are  required  to  complete  the  form. 

f>.  Review  the  appropriate  sources,  and  determine  the  number  of 
unique  positions  in  the  team  type.  In  Block  6  record  the 
position  titles  in  a  hierarchial  manner  (highest  level 
first). 

To  the  right  of  the  position  title  entered  In  Block  6, 
enter  the  MOS  code  of  the  person  who  is  most  likely  to  fill 
or  occupy  the  position.  The  MOS  code  should  be  entered  as 
a  five  position  code  (e.g.t  12B10).  In  addition,  enter 
the  typical  rank  of  the  position  holder  (e.g.,  E4). 

If  the  position  title  MOS  code,  or  rank  cannot  be  deter¬ 
mined  from  the  documentation,  consult  an  SME  or  a  team 
member  incumbent. 

7.  In  Block  7  enter  the  number  of  people  in  the  team  type  that 
hold  each  of  the  position  titles.  At  the  bottom  of  Block 
7,  enter  the  total  number  of  people  in  the  team  type.  If 
two  or  more  pages  are  used  to  record  the  position  titles, 
then  enter  the  total  number  of  individuals  in  the  team  type 
on  the  last  page  in  the  box  provided  at  the  bottom  of  Block 
7. 

8.  In  Block  8  enter  the  equipment  assigned  to  each  of  the 
position  titles.  This  information  may  be  difficult  to 
obtain  from  the  documentation,  since  documentation 
typically  does  not  associate  equipment  use  with  the  various 
position  1 1 1 1 <*8 .  For  this  reason,  the  following  approach 
should  be  taken: 

a.  Mike  arrangements  to  discuss  the  equipment  assign¬ 
ment  with  an  SME  (if  your  are  not  an  SME). 

b.  Photcopy  the  list  of  equipment  in  the  TO&E  or  other 
documentation. 

c.  Then  interview  the  SME.  Provide  the  SME  with  the 
following  instructions: 

.  Review  the  equipment  list,  item  by  item,  and  for 
each  item  indicate  wlto  (position  title)  typically 
uses  the  equipment. 

d.  If  the  SME  indicates  multiple  users  of  the  equip¬ 
ment,  then  assign  the  equipment  to  the  various 
users . 


70 


e.  It  tlu*  SMIi  indicates  that  the  equipment  Is  assigned 
on  llic  basis  of  tin.-  various  missions  (l.e.,  Lite 
assignment  of  equipment  varies  from  mission  to 
mission),  then  create  an  equipment  category 
designated  "Assigned  by  mission.” 


Nominal  Team  Structure  Organizational  Chart  (Form  2A) 


Form  2A,  the  Nominal  Team  Structure  Organizational  Chart,  is 
designed  to  graphically  represent  the  relationships  between  the 
position  titles  recorded  on  Form  2  (e.g.,  the  chain  of  command  and/or 
authority).  The  instructions  for  completing  Form  3  are  as  follows: 

1.  Complete  Blocks  1 ' through  5  in  the  usual  manner.  Be  sure 
that  the  information  entered  in  these  blocks  is  identical 
to  the  information  entered  on  Form  1  and  Form  2. 

2.  In  Block  6  enter  a  hlerarchial  chart  of  the  position  titles 
recorded  on  Form  2.  There  should  be  a  block  or  box  diagram 
which: 

a.  Has  the  team  leader  at  the  top  (squad  leader, 
platoon  leader,  section  leader,  etc.). 

b.  Shows  the  relationships  between  the  various  position 
litles.  Each  position  title  recorded  on  Form  2  must 
be  represented.  There  must  be  as  many  blocks  (or 
boxes)  as  there  are  total  number  of  team  type 
members  (the  number  of  boxes  should  correspond  to 
tlx*  number  entered  at  the  bottom  of  Block  7  on  Form 
2).  These  relationships  should  be  represented  as 
lines  connecting  the  boxes  together  Illustrating  how 
the  position  titles  are  briefly  related  to  each 
other.  The  organizational  chart  should  not  be 
influenced  by  the  missions  performed  by  the  selected 
team  type  (l.e.,  the  chart  should  be  invariant  with 
respect  to  the  missions  performed  by  the  team  type). 

Each  of  the  boxes  should  be  labeled  by  its  corresponding 
posit  ion  lilli— -In*  sure  to  use  the  same  position  titles  as 
recorded  on  Form  2  to  avoid  confusion. 

The  information  recorded  on  Form  2A  can  typically  be  obtained  from  the 
AKTEP  manual  or  TO&K.  You  may  elect  to  verify  the  organizational  chart 
by  having  an  SHE  review  it.  Although  the  basic  information  is  provided 
In  the  AKTEP  manual  and/or  the  TO&K,  you  should  be  made  aware  that 
often  these  two  sources  do  not  represent  all  the  position  titles 
encountered  in  kite  team  Ly|x>  ot  interest.  However,  it  is  usually  not 


difficult  to  Infer  tht*  relationships  among  the  team  members  (position 
titles)  from  the  Information  provided  lit  the  two  sources,  particularly 
If  you  are  familiar  with  the  team  type  of  interest. 


Summary  of  Step  2 


Once  the  three  forms  (Forms  1,  2,  and  2A)  of  Step  2  are  completed, 
the  recorder  has  what  is  called  a  team  or  team  type  description.  This 
team  type  description  includes  the  following: 

1.  A  list  of  all  the  ARTBP  missions  performed  by  the  team  type 
type. 

2.  A  list  of  the  position  titles  which  comprise  the  team  type 
nominal  structure  (including  the  total  number  of  team 
members  in  the  nominal  team). 

3.  A  list  of  the  equipment  used  by  the  team  type  (recorded  by 
position  titles). 

4.  An  organizational  chart  of  the  team  type  showing  the 
relationships  among  the  team  members. 

Notice  that  all  this  information  is  invariant  with  respect  to  the 
various  missions  performed  by  the  selected  team  type;  i.e.,  none  of  the 
Information  recorded  in  Step  2  should  be  mission  specific. 
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SELKCT  MISSIONS  TO  BK  DESCRIBED  (STEP  3) 


After  completing  the  team  type  description  (the  first  three 
forms),  the  next  step  is  to  select  the  missions  that  will  be  described 
in  detail.  There  are  several  selection  approaches  that  can  be  used  to 
select  missions  to  be  described: 

1.  Describe  every  mission  performed  by  the  team  type. 

2.  Select  critical  missions  to  be  described;  i.e.,  sample  from 
the  missions  performed  by  the  team  type.  This  approach  is 
probably  less  precise  than  the  first  approach,  since  errors 
can  be  made  in  sampling. 

3.  Determine  which  mission  or  missions  a  team  type  is  likely 
to  have  problems  mastering,  and  describe  those  missions. 

The  following  approach  is  recommended  to  sample  the  missions  to  be 
described 

1.  Make  arrangements  to  interview  an  SME  or  an  incumbent  team 
type  member,  preferably  the  same  SME  used  to  complete 
Form  1.  (If  you  are  an  SME,  this  does  not  apply  to  you.) 

2.  Before  interviewing  the  SME  or  Incumbent,  carefully  review 
the  mission  list  attached  to  Form  1.  Also  review  Form  1 
for  the  changes  to  the  list..  Be  sure  the  list  is 
relatively  up-to-date. 

3.  Eliminate  the  missions  which  you  believe  can  be  safely 

eliminated  from  consideration.  If  you  are  selecting 
missions  to  develop  team  training,  some  missions  which 
involve  generating  reports  and  managing  personnel  would 
probably  be  impacted  by  team  training,  and  therefore,  | 

should  be  elminated. 

4.  Before  meeting  with  the  SME  or  incumbent,  read  as  much  as 
possible  about  the  remaining  missions  in  order  to 
familiarize  yourself  with  them.  It  is  suggested  that  you 
read  the  description  of  the  missions  as  given  in  the  AKTEP 
manual.  You  may  also  want  Lo  obtain  specific  field  manuals 
to  review. 

5.  Meet  with  the  SME  or  incumbent.  Inform  him  or  iter  of  the 

missions  that  have  been  eliminated  from  consideration.  .  ■ 


^The  approach  suggested  has  not  been  verified  or  tested.  It  Is 
scheduled  to  be  verified  in  the  second  and  third  years  of  the  current 
effort. 


Review  each  of  the  missions  with  the  SME.  Have  the  SME 
informally  rank  the  missions  from  high  to  low  on  combat 
importance  or  criticality.  This  ranking  should  not  be 
official,  but  only  an  indication  of  what  is  relatively  more 
or  less  important  during  combat. 

Starting  with  the  mission  that  is  judged  most  Important 
(and  going  to  the  least  important),  perform  the  following 
steps:  ’ 

a.  Review  the  missions  within  the  Major  Mission 
Operations,  and  ask  the  SME  or  incumbent  to  rank 
them  in  terms  of  frequency. of  performance;  e.g.,  how 
often  is  the  mission  likely  to  be  performed  during 
war?  The  estimate  does  not  have  to  be  accurate. 

The  purpose  is  to  rank  order  the  missions  within 
each  Major  Mission  Operation. 

Designate  those  missions  with  high,  moderate,  and 
low  frequencies.  This  can  be  accomplished  by 
recording  to  the  left  of  the  mission  title,  the 
letter  "H“  for  high,  the  letter  "M"  for  moderate, 
and  the  letter  “L”  for  low  (on  Form  1). 

b.  If  you  are  concerned  about  developing  team  training 
for  the  selected  team  type,  also  ask  the  SME  for  a 
judgment  concerning  which  missions  are  the  most 
difficult  missions  to  master  or  to  train.  Record 
the  SMEs  response  to  the  left  of  the  mission  title 
with  an  "0"  on  Form  1. 

c.  You  may  also  elect  to'  ask  the  SME  for  his  judgment 
concerning  which  missions  within  the  Major  Mission 
Operation  involve  the  most  difficult  teamwork.  The 
SME,  however,  may  have  difficulty  in  answering  this 
questions  for  several  reasons.  These  are:' 

Teamwork  is  a  difficult  concept  to  explain, 
and  the  SMF/s  perception  of  teamwork  may 
differ  from  yours  as  well  as  other  SMEs. 

.  The  SME  may  confuse  the  difficulty  of  the 
individual  tasks  involved  in  the  mission  with 
the  teamwork. 

However,  If  you  elect  to  obtain  this  Information, 
record  the  SME's  response  to  the  left  of  the  mission 
title  with  the  letters  "TVf  (meaning  high 
teamwurk),  again  on  Form  1. 

d.  Repeat  the  process  with  the  next  Major  Mission 
Operation. 
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7.  At  this  point.  It  may  be  decided  to  verify  the  judgments 
made  by  the  SHE  or  incumbent,  since  SMEs  will  vary  in  their 
judgments  about  the  missions.  Because  of  this,  it  may  be 
reasonable  to  duplicate  the  above  six  substeps  with  another 
SME  or  incumbent. 

Verification  should  not  be  viewed  as  a  necessity.  The 
information  provided  by  the  SME  is  only  to  provide  guidance 
in  selecting  missions  to  be  described.  Although  errors  may 
be  introduced  if  a  giv?n  SME's  judgments  are  not  verified, 
the  seriousness  of  errors  will  not  be  enough  to  destroy  the 
intent  of  the  effort. 

8.  When  all  information  has  been  collected  from  the  SMEs  or 
job  incumbents,  the  missions  to  be  described  are  selected 
next.  The  selection  process  is  somewhat  subjective  and  is 
done  by  logical  analysis  of  information  obtained  from  SMEs. 
The  goal  of  the  selection  process  is  to  select  10-50 
percent  of  the  mission  for  detailed  descriptions,  based  on 
the  considerations  discussed  below. 

a.  Determine  what  percentage  of  the  total  number  of 
missions  the  missions  indicated  on  Form  1  represents 
(divide  the  number  of  indicated  missions  by  the 
total  number  of  missions  performed  by  the  team 
type).  If  this  figure  is  less  than  ten  percent,  you 
should  select  additional  missions  to  be  described, 
since  describing  less  than  ten  percent  of  the 
missions  performed  by  a  team  type  will  not  provide 
enough  data  for  any  purpose  except  developing  team 
training  for  single  missions. 

b.  Determine  the  amount  of  time  available  to  describe 
the  mission  sample.  Describing  a  typical  mission 
for  an  averagersized  team  type  will  require  an 
average  of  about  20  hours  (four  to  eight  hours  of 
documentation  review,  four  to  eight  hours  observa¬ 
tion  {time,  and  eight  to  ten  hours  preparing  the 
description).  This  estimate  does  not  include  time 
for  liaison,  acquiring  documentation,  or  travel  for 
observation.  The  estimate  of  the  time  required  for 
a  mission  assumes  that  the  preparer  is  naive  with 
respect  to  the  mission  to  be  described,  but  not  with 
respect  to  the  Description  Method. 

Since  the  average  time  to  describe  a  mission  is 
about  20  hours,  divide  the  time  available  for 
describing  missions  (hours)  by  20.  This  gives  an 
■,  estimate  of  the  number  of  missions  that  can  be 
described  in  the  time  available. 
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c.  Compare  the  number  of  missions  that  you  estimated 
Lhere  will  be  time  to  describe  (in  Step  b  above) 
with  ten  percent  of  the  total  number  of  missions 
performed  by  the  team  type.  If  the  time  available 
to  describe  missions  will  allow  description  of  less 
than  ten  percent  of  the  missions  performed,  STOP, 
and  consult  with  your  supervisor.  Less  than  ten 
percent  of  the  missions  performed  by  a  team  type 
will  probably  not  be  a  satisfactory  sample  for  most 
uses  of  the  descriptions.  Your  supervisor  may  elect 
to  stop  the  effort  altogether,  or  may  allow  more 
time  for  descriptions,  or  may  tell  your  to  describe 
what  Is  possible  in  the  amount  of  time  available. 

You  and  your  supervisor  must  resolve  this  issue. 

If  more  that  ten  percent  of  the  total  missions  caa 
be  described  In  the  time  available,  continue  with 
mission  selection.  If  time  is  available  for  more 
than  50  percent  of  the  mlsstons  to  be  described,  it 
is  probably  best  to  restrict  the  descriptions  to  no 
more  than  50  percent  of  the  missions.  Describing 
more  than  50  percent  of  all  missions  performed  by  a 
team  probably  does  not  add  any  more  relevant 
lnforamtlon  than  describing  50  percent  of  the 
missions,  if_  the  missions  are  carefully  selected. 

d.  Select  the  specific  missions  to  be  described.  The 
following  general  items  of  guidance  are  provided  to 
assist  in  selecting  specific  missions: 

.  Select  at  least  one  mission  from  each  of  the 
Major  Mission  Operations.  If  this  is  not 
possible,  select  missions  from  the  Major 
Mission  Operations  that  were  judged  the  most 
important  for  combat.  If  possible,  select 
missions  from  .he  Major  Mission  Operations  in 
the  same  proportion  as  the  distribution  of  the 
total  number  of  missions  across  Major  Mission 
Operations  (l.e.,  if  Major.  Mission  Operation 
”A”  contains  40  percent  of  all  tasks  performed 
by  the  teem,  then  about  40  percent  of  the 
missions  selected  should  pertain  to  Major 
Mision  Operation  ”11”). 

.  The  missions  selected  should  have  the  same  (or 
about  the  same)  distribution  of  low,  moderate, 
and  high  mission  performance  frequencies,  as  in 
the  entire  population  of  missions.  This 
frequency  guidance  must  be  considered  along 
with  the  questions  of  difficulty  of  mastery  of 
the  mLssion,  teamwork  involved  In  the  mission, 
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and  the  need  for  systematic  training  for  the 
missions.  In  general,  the  objective,  should  be  to 
prefer  missions  tliat  are  more  difficult  to  master, 
involve  more  teamwork,  and  are  judged  to  require 
systematic  training,  while  keeping  high,  moderate, 
and  low  mission  performance  frequencies  balanced  in 
the  sample.  Many  missions  will  not  meet  all  three 
of  these  criteria.  Where  all  the  missions  to  be 
selected  do  not  meet  all  three  criteria,  then 
missions  meeting  two  of  the  criteria  should  be 
preferred  in  the  sample,  after  the  mission  that  met 
all  three  criteria  arc  selected.  Missions  meeting 
only  one  of  the  criteria  should  be  considered  last, 
if  more  missions  are  needed  to  make  up  the  sample  of 
missions  to  be  described. 

Indicate  tiie  missions  to  be  described  on  Form  1  by 
placing  a  capital  "S"  in  the  left  margin  next  to 
each  mission  selected. 

9.  After  the  sample  has  been  selected,  and  the  sample  is 
checked  against  the  guidelines,  the  sample  should  be 
reviewed  by  an  SMC  or  incumbent.  The  purpose  of  this 
review  is  to  determine  the  following  issues: 

a.  Are  any  of  the  selected  missions  extremely  similar 
to  each  other  in  terms  of  content  and/or  teamwork, 
so  that  one  or  more  of  the  selected  missions  can  be 
eliminated  from  the  sample?  The  sample  should  not 
contain  duplicate  missions. 

b.  Are  the  selected  missions  going  to  be  easy  to 
arrange  from  an  observation  point  of  view?  it 
should  bo  noted  that  to  describe  a  mission,  the 
mission  will  have  to  be  observed  by  the  describer. 
Thus,  the  sample  should  contain  missions  which  are 
consistent  with  what  might  occur  in  a  normal  field 
exercise.  For  example,  when  developing  this 
description  technique,  mechanized  Combat  Engineer 
Platoons  were  observed.  One  of  the  missions 
scheduled  to  be  observed  was  the  construction  of,  a. 
log  crib.  Another  mission  scheduled,  to  be  observed 
was  the  breaching  of  a  log  crib.  These  missions 
were  selected  because  they  were  consistent  and 
placed  fewer  demands  on  the  unit  being  observed.  If 
a  log  crib  was  constructed,  then  it  would  be  rela¬ 
tively  easy  to  arrange  for  the  log  crib  to  be 
breached  ns  part  of  field  exercise.  It  should  also 
be  noted  that  constructing  a  log  crib  appears  under 
a  different  Major  Mission  Operation  than  breaching  a 
lob  crib  (AKTEP  5-25). 
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The  S?1K  or  incumbent  might  provide  some  suggestions  for 
adjusting  tlve  sampLe  after  tlie  review.  Make  adjustments  in 
the  sample  by  deleting  some  missions  selected  adding 
other  missions  not  originally  selected  to  replace  the 
deleted  missions. 

The  procedures  should  provide  you  some  idea  of  the  missions  that 
you  want  to  describe.  However,  the  selected  mission  list  is  not  carved 
in  granite.  When  arrangements  are  made  in  Step  4  to  observe  the 
selected  missions,  it  will  be  discovered  that  the  mission,  list  may 
have  to  be  revised,  because  the  cooperating  FORSCOM  unit  (or  team  type) 
will  suggest  other  missions  (e.g.,  they  may  not  have  the  necessary 
equipment  to  perform  some  of  the  selected  missions).  Thus,  the  sample 
of  missions  to  be  observed  may  be  continually  modified.  It  should  not 
be  forgotten  that  the  purpose  of  sampling  is  to  select  missions  which 
are  representative  of  tlie  missions  performed  by  the  team  type. 


Summary  of  Step  3 

Selecting  the  missions  to  be  described  depends  upon  how  you  plan 
to  use  the  mission  descriptions.  If  you  are  developing  performance 
measures,  only  those  missions  for  which  you  will  develop  performance 
measures  will  be  selected.  If  you  are  developing  mission  specific  team 
training,  then  you  should  select  only  those  missions  for  which  team 
training  must  be  developed.  If  you  are  tasked  with  developing  general 
team  training  for  team  type,  then  you  must  carefully  sample  the 
missions  performed  by  the  team  type.  The  sample  must  be  representative 
of  the  population  of  missions  performed  by  the  team  type.  Guidance  for 
sampling  missions  lias  been  provided  in  tills  section. 

However,  it  should  he  realized  that  the  suggested  sampling 
procedure  Is  not  rigorous.  In  fact,  the  sampling  procedure  is  rather 
subjective  and  is  designed  to  consider  possible  uniqueness  of  the  team 
type.  The  sampling  procedures  employ  subjective  judgments  based  upon 
the  frequency  of  performance  of  the  missions,  the  amount  of  teamwork 
Involved  in  the  missions,  the  frequency  of  missions  in  a  combat 
situation,  and  need  to  provide  mission  training.  .The  sample  also 
selected  is  moderated  by  the  cooperation  and  availability  of  teams  to 
actually  perform  tlie  selected  missions.  The  list  of  selected  missions 
may  change  as  the  description  process  continues. 


DESCRIBE  THE  SELECTED  MISSIONS  (STEP  4) 


The  last  step  Is  to  describe  in  detail  the  specific  missions 
selected.  This  is  by  far  che  most  difficult  and  time  consuming  step. 
However,  it  is  also  tlx;  step  that  generates  tlie  most  useful  and 
meaningful  data  about  the  team  type  of  interest.  At  the  completion  of 
Step  2,  a  limited  team  type  description  is  generated.  At  the 
completion  of  Step  4,  description  of  a  specific  team  mission  is 
generated. 


Step  4  requires  the  completion  of  five  forms  for  each  mission: 


1.  General  Mission  Information  (Form  3). 

2.  Mission  Situational  Map  (Form  3A). 

3.  Actual  Team  Structure  (Form  4). 

4.  Actual  Team  Structure — Nested  Team  Description  (Form  4A). 


5.  Mission  Team  Activity  Description  (Form  5  -  cany.  Form  5s 
will  be  generated  for  each  mission). 


The  Information  for  these  funs':  can  be  derived  from  three  basic 
sources:  military  documentation;  and/or  SMKs;  and/or  observation  of 
actual  teams  performing  die  selected  missions.  It  Is  not  recommended 
that  mission  descriptions  be  generated  from  documentation  alone. 
Although  it  is  possible  to  generate  mission  descriptions  solely  from 
reading  doc  mien tat  ion ,  the  completeness  of  such  descr Lpticns  is 
suspect.  Documentation  typically  does  not  address  or 
and  it  is  the  teamwork  in  the  mission  that  inust  be  described.  A  useful 
source  for  generating  mission  descriptions  which  highlight  t;eamwork  is 
SMEs.  SHEs  sometimes  do  not  to  agree  on  how  missions 
on  the  kinds  of  teamwork  involved  during  the  mission. 


views  add  greatly  to  the  descriptions  possible  only  from  observation. 
Observation  is  recommended,  if  at  all  possible,  since  this  is  the  most 
complete  source  of  detailed  reLevant  team  behavior  data. 


discuss  teamwork. 


are  performed  or 
but  SHE  inter- 


Prcliminary  Activitlc j 


The  first  substep  of  Step  4  is  to  perform  some  preliminary 
planning  activities.  These  are: 


1.  Make  arrangements  to  observe  the  mission 
selected  missions).  If  at  ail  possible, 


(and  all  other- 
specific  team  of 
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the  team  type  which  is  believed  to  be  an  outstanding  team 
sltould  lie  selected  for  observation.  However,  this  is  not 
always  possible.  The  quality  of  a  specific  team  is  not 
usually  known,  and  good  teams  are  not  always  available  to  ' 
be  observed.  But  In  spite  of  these  practical  limitations, 
you  should  try  to  identify  a  good  actual  team  of  the  team 
type  of  interest. 

Make  contact  with  the  selected  team  and  determine  when 
their  next  field  exercise  is  to  occur.  Determine  what 
missions  are  to  be  part  of  the  field  exercise  for  the 
selected  team.  Discuss  with  the  unit  which  missions  will 
be  observed.  If  necessary,  revise  your  list  of  missions. 
However,  make  sure  the  revisions  do  not  violate  the 
guidelines  that  have  been  provided  in  Step  3.  Also, 
explain  that  you  WILL  NOT  be  evaluating  the  teams,  only 
observing  the  teamwork  involved  in  the  performance  of  the 
missions. 

If  more  than  one  mission  is  to  be  described,  then  you  must 
decide  whether  the  same  team  will  be  be  observed  for  ail 
the  missions  that  must  be  described.  Little  guidance  can 
be  provided  in  making  this  decision.  In  order  to  provide 
some  continuity  in  the  descriptions,  it  seems  reasonable 
that  the  same  actual  team  should  he  observed  throughout  the 
observation  phase.  However,  in  practice,  this  goal  may  he 
difficult  to  reach.  It  is  not  known  what  effects  observing 
.different  teams  might  cause  in  identifying  team  training 
requirements  or  in  the  creation  of  team  performance 
measures. 

Similarly,  it  is  not  known  if  more  than  one  team  should  be 
observed  per  mission  selected,  from  a  theoretical  point  of 
view  it  does  not  make  good  sense  to  base  team  type  training 
decisions  on  the  observation  of  only  one  team  which  is  a 
member  of  the  team  tyoe.  On  the  surface,  it  makes  more 
sense  to  observe  a  representative  sample  of  teams 
performing  the  selected  misslon(s).  This  is  particularly 
true  if  the  objective  Is  to  develop  team  training  which  Is 
appropriate  for  every  actual  team  tliat  is  a  member  of  the 
selected  team  type.  However,  observing  more  than  one 
actual  team  performing  each  mission  complicates  both  the 
recording  and  analysis  processes.  In  terms  of  recording, 
you  would  have  to  lecord  a  mission  description  once  for 
each  actual  team  observed.  In  terms  of,  analysis,  each  of 
the  descriptions  of  the  mission  would  have  to  be  analyzed 
and  a  single  standard  or  representative  description 
derived.  It  is  anticipated  that  the  second  and  third  years 
of  this  research  effort  will  shed  some  Light  on  the 
requirements  for  the  number  of  teams  observed  per  mission. 
For  the  time  being,  tlie  following  is  suggested: 
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a.  Select  an  actual  team  of  the  team  type  that  Is 
believed  to  be  a  good  team. 

b.  Try  to  observe  the  team  performing  all  the  missions 
that  must  be  described. 

c.  If  after  observing  the  selected  actual  team 
performing  the  selected  mission(s)  you  feel 
uncomfortable  about  the  teamwork  involved  in  the 
mission,  then  you  should  repeat  the  observation 
process  either  on  the  same  actual  team  or  on  another 
team  of  the  same  type. 

After  making  contact  with  the  FORSCOM  unit,  you  should  know 
which  missions  will  actually  be  observed.  For  those 
missions  that  will  be  observed,  obtain  the  military 
documents  that  describe  the  missions  in  detail. 

The  quality  of  documentation  varies  considerably.  Some  of 
tlio  available  documentation  provides  sufficient  detail  to 
estimate  the  kinds  of  teamwork  involved  in  a  mission. 

Other  documentation  provides  only  a  blanket  description  of 
the  mission.  Thus,  you  should  screen  the  documentation 
that  has  been  obtained,  and  select  the  documentation  that 
you  believe  provides  the  most  detail.  If  you  are  not  an 
SHE,  an  SME  might  be  able  to  provide  some  guidance  in 
selecting  the  most  useful  and  Informative  documentation. 

The  documentation  should  be  read  carefully.  The  first 
reading  should  familiarize  you  with  the  activities  and 
events  of  the  mission.  During  the  second  reading,  more 
careful  attention  should  be  directed  to  mission  details. 
Notes  may  be  taken  to  highlight  areas  of  teamwork  which  are 
unclear  from  the  documentation.  For  example,  it  is  useful 
to  note  the  following: 

a.  Does  the  mission  require  the  team  to  be  organized 
Into  nested  teams  or  into  smaller  units  or  sections? 
For  example,  if  you  are  to  describe  a  platoon 
mission,  you  need  to  ask  yourself,  "Is  the  platoon 
organized  inco  squads  or  parties  for  this  particular 
mission?"  An  example  of  a  nested,  team  organization 
Is  n  mechanized  Combat  Engineer  Platoon,  which  is 
organized  Into  four  separate  parties  during  the 
Installation  of  a  tactical  minefield  (a  siting 
party,  a  marking  party,  a  laying  party,  and  a 
recording  party).  Another  example  is  an  Infantry 
squad  which  is  typically  organized  into  two  fire 
teams. 


You  nuiy  not  be  able  to  tell  from  documentation  if  a 
nested  team  organization  Is  used  in  a  mission. 
Because  the  documentation  may  be  unclear,  the 
following  guidelines  are  provided.  A  nested  team 
organization  should  be  suspected  if  (from  the 
documentation)  you  determine: 

.  The  team  type  is  large  (e.g.,  greater  than 
ten). 

.  The  mission  requires  seve~.  1  discrete  activi¬ 
ties  to  be  performed  in  p  '‘altel  by  tie  entire 
team  (e.g.,  a  group  of  sc.  ^.i era  performs  "X”; 
while  another  group  of  solders  from  the  team 
performs  "Y“;  while  another  j,,*oup  performs 
"Z,”  and  so  on). 

.  The  team  type  is  naturally  organized  into 
smaller  units  (e.g.,  platoons ■ organized  into 
squads),  and  all  these  smaller  units  perform 
the  same  activities  at  the  same  time,  but  as 
individual  units.  For  example,  in  a  platoon 
movement  to  contact,  all  the  squaas  are  doing 
generally  the  same  thing  at  the  same  time;  ■ 
thus  the  squads  can  be  considered  nested 
teams. 

.  The  division  of  labor  in  the  team  requires  a 
subgroup  of  soldiers  to  carry  out  a  single 
duty  or  responsibility  throughout  the  mission; 
e.g.,  a  subset  of  soldiers  are  required  to 
provide  security  for  the  whole  unit  while  the 
mission  is  conducted.  The  soldiers  providing 
security  can  be  considered  a  nested  team,  even 
though  they  may  be  spread  out  and  are  not 
physically  located  close  to  each  other. 

if  any  of  these  conditions  appear  to  prevail,  a 
nested  team  organization  should  be  suspected.  If 
the  documentation  does  not  make  these  conditions 
clear,  then  you  should  record  in  your  notes  that  It 
is  important  during  observation  of  the  mission  to 
determine  (f  a  nested  team  organization  exists.? 


?When  you  have  been  tasked  with  the  responsibility  to  describe  a 
mission  performed  by  a  large  team  (e.g,,  greater  than  ten  members),  it 
is  useful  to  force  a  nested  tenm  structure.  It  is  difficult  to 
observe  a  large  team,  and  if  thu  team  can  be  organized  into  smaller 
units,  then  the  observation  demands  become  reasonable  and  acceptable. 
Thus,  when  dealing  w<th  a  large  team,  try  to  hypothesize  "natural'* 
nested  teams,  even  if  the  concept  of  nested  teams  has  to  be 
stretched. 


b.  If  you  lave  determined  from  documentation  that  a 
nested  team  organization  or  structure  extsts,  then 
ask  yourself  the  following  question: 

Does  the  team  stay  In  the  same  nested  team 
structure  throughout  the  mission,  or  are  nested 
teams  formed,  disbanded,  and  new.  nested  teams 
formed  later  in  the  mission? 

You  should  suspect  a  stable  nested  team  structure  if 
the  nested  team  is  doing  the  same  thing  (the  same 
activity)  throughout  the  entire  mission.  You  should 
suspect  a  variable  nested  team  structure  if  any  of 
the  following  conditions  are  evident: 

.  The  size  of  the  nested  team  appears  to  change 
during  the  mission. 

.  A  nested  team  appears  not  to  be  engaged  in 
some  activity  throughout  tl«e  entire  mission 
(i.e.,  they  appear  to  perform  a  set  of 
activities  during  only  a.  certain  segment  of 
the  mission,  and  are  not  mentioned  in  the 
documentation  again). 

For  each  nested  team  identified  in  the  documenta¬ 
tion,  it  is  important  to  determine  If  the  nested 
team  is  stable  (static)  throughout  the  mission,  or 
dynamic  (variable). 

If  you  cannot  answer  this  question  from  the  documen¬ 
tation,  record  in  your  notes  that  it  Is  not  certain 
if  the  nested  teams  remain  constant  throughout  the 
mission  or  if  the  nested  teams  exist  for  some  period 
of  time  and  are  then  disbanded.  The  stability  of 
the  nested  teams,  will  have  to  be  determine*!  during 
observation,  if  it  is  not  clear  from  the  documenta¬ 
tion. 

c.  If  you  suspect  a  nested  team  structure  from  the 
documentation,  then  you  should  try  to  pinpoint  the 
dependencies  that  occur  between  the  various 
nested,  teams.  That  Is,  you  should  try  to  Identify 
(from  documentation),  the  interactions  between  the 
various  nested  teams.  The  documentation  typically 
wilt  not  make  these  nested  team  dependencies 
explicit.  Thus,  you  must  analyze  the  situation  and 
try  to  logically  derive  these  dependencies  from 
documentation. 
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In  order  to  obtain  a  full  understanding  of  any 
nested  team  dependencies,  you  may  construct  a  matrix 
in  your  notes.  The  rows  and  columns  of  the  matrix 
should  each  contain  a  label  indicating  each  identi¬ 
fied  nested  team.  Only  the  upper  portion  of  the 
matrix  will  be  needed.  For  each  cell  of  the  matrix, 
you  should  think  about  the  possible  dependencies 
between  the  nested  teams  corresponding  to  the  cell 
In  light  of  the  documentation’s  description  of  the 
activities  of  each  of  the  nested  teams.  For  each 
cell  of  the  matrix,  ask  the  following  questions: 

Is  there  a  product  tranferred  between  the  two 
nested  teams  of  interest?  If  "Yes,"  then 
enter  in  the  appropriate  cell  the  product  that 
is  transferred. 

.  Is  there  a  procedural  dependency  between  the 
two  nested  teams  of  interest?  You  should 
suspect  a  procedural  dependency  If  one  nested 
team  must  perform  a  set  of  activities  before 
another  nested  team  can  perform  Its  assigned 
responsibilities  (e.g.,  when  Installing  a 
tactical  minefield,  the  siting  party  nested 
team  must  complete  a  majority  of  their 
assignment.*:  before  laying  party  nested  teams 
can  begin  their  work). 

If  a  procedural  dependency  Is  evident,  enter  a 
phrase  indicating  the  dependency  in  the 
appropriate  cell  (e.g.,  "laying  party  cannot 
begin  until  siting  party  has  finished"). 

.  Are  there  any  virtual  (implied)  dependencies 
between  the  nested  teams  of  Interest?  You 
should  suspect  a  virtual  dependency  between 
nested  teams  If:  (a)  there  are  two  or  more 
nested  teams  which  are  performing  identical 
activities,  but  are  organized  as  separate  and  . 
individual  nested  teams;  e.g.,  when  laying  a 
tactical  minefield  there  may  be  more  than  one 
laying  party,  or  (b)  one  nested  ceam  is 
providing  security,  while  other  nested  teams 
or  Lite  team  at  large  are  engaged  in  other 
activities.  If  a  Virtual  dependency  is 
suspected,  record  a  phrase  indicating  the 
nature  of  the  dependency  in  the  appropriate 
roll  of  the  matrix  (e.g,  "nested  team  'A' 
provides  security  for  ner.ted  team  ’3'). 


.  Are  there  any  communicative  dependencies 
between  the  nested  teams  of  interest? 
Unfortunately,  there  are  probably  too  many  of 
these  to  record  In  the  matrix.  When  reading 
the  documentation,  one  can  imagine  tuny 
communicative  dependencies.  In  fact,  o.ie  can 
speculate  that  at  least  one  verbal  dependency 
would  almost  always  accompany  each  of  the 
other  types  of  dependencies. 

Tlie  matrix  process  will  require  careful  reading  of 
the  documentation  and  force  you  to  think  about  the 
dependencies  that  might  exist  betwee**  nested  team 
and  all  other  nested  teams.  It  will  a.  so  highlight 
areas  to  which  you  must  pay  particnla*  attention 
when  you  actually  observe  the  misalcn  being 
performed. 

When  reading  the  documentation ,  It  is  important  not 
only  to  be  sensitive  to  tnc  dependencies  between 
nested  teams,  but  aLso  about  the  dependencies  that 
occur  between  each  nested  team  member  within  a 
nested  team.  You  may  elect  to  speculate  about  these 
dependencies,  particularly  these  that  the  documenta¬ 
tion  does  not  clearly  e.cpiain.  These  notes  can  also 
be  used  to  guide  your  observation  of  the  mission. 

You  will  find  it  useful  to  construct  a  matrix, 
similar  to  the  cv  ■’escribed  above  for  nested  teams, 
to  Identify  the  t.e  pendencies  between  the  team 
members  ot  oar;,  of  the  nested  teams,  one  at  a  time. 
If  there  are  iso  nested  tea  as,  then  only  one  matrix 
should  be  formed,  the  one  fo”  the  team  itself.  You 
.should  start  with  the  smallest  -tested  team,  the  one 
with  t>»  fewest  team  «■•:>.?»  Record,  in  the  cells 
of  fh  .mv-trlx,  acy  so  pr-  f-. o  ^pendencies  between 
the  nested  tear.  vY.ch  are  unclear  from 

reading  the  doccv.-rtla*  »n-i ;  dependencies  which  must 
be  cinr'ifleci  onri-p  'lie-  observation  phase.  Recall 
that  there  are  ^evec  1  hinds  of  team  member 
dependencies  to  think  about: 

.  Communicative  dependencies  (o.g.,  hand. 

signals,  verbal  instructions,  radio  commtinlca- 
t Ions ,  etc . ). 

.  Product  dependencies  (i.e.,  the  transfer  of  a 
product  between  the  team  members;  e.g.,  the 
passing  <>t  a  mortar  round,  the  transfer  of 
mines,  etc.). 


.  Procedural  dependencies  (i.e.,  sequential 
actions  between  team  members  where  one  team 
member  must  perform  a  set  of  activities  before 
another  team  member  can  begin,  end,  or 
continue  his  or  lier  activities). 

;  Virtual  dependencies  (l.e.,  implied  depend¬ 
encies — the  providing  of  security,  or  two  or 
more  team  members  performing  the  same 
activities  at  the  same  time  in  order  to 
compLete  an  event  or  a  set  of  activities). 

Remember,  in  your  notes  you  need  not  specify  every 
dependency,  only  those  which  you  feel  are  unclear 
from  the  documentation.  You  should  not  be  afraid  or 
hesitant  to  speculate  about  possible  dependencies. 
The  documentation  probably  will  not  describe  every 
dependency,  and  may  stimulate  you  to  hypothesize 
dependencies. 

e.  There  are  certain  dependencies  which  are  frequently 
or  commonly  "missed"  by  describers  when  reading  the 
documentation.  Perhaps  a  discussion  of  these  will 

assist  you: 

.  Type  II  virtual  dependencies.  A  Type  II 

virtual  dependency  may  exist  if  the'  team  or  a 
nested  team  is  tasked  with  the  responsibility 
to  perform  a  set  of  activities,  but  specific 
assignments  within  this  envelope  of  responsi¬ 
bility  are  not  given.  For  example,  when 
constructing  an  assault  ribbon  bridge,  the 
assembly  section  (a  nested  team  of  the  larger 
team)  has  many  activities  which  must  oe 
performed  when  attaching  a  bay  to  an  existing 
raft.  Latches  must  be  thrown,  the  connecting 
mechanism  must  be  locked  into  place,  etc. 
Assembly  sections  have  been  observed  that  do 
not  give  specific  assignments  to  specific  team 
members.  The  team  members  know  what  has  to  be 
done,  and  the  completion  of  individual  activi¬ 
ties  is  self-assigned.  For  example,  when  a 
hay  arrives  one  team  member  will  throw  the 
lalclw's.  He  Ikisii'C  been  directed  to  do  tills, 
hut  knows  it  needs  to  be  done  and  does  it. 
Another  team  number  will  sclf-sclcct  himself 
to  perform  another  individual  activity.  The 
self  assignment  is  not  consistent  (i.e.,  on 
one  bay  a  team  member  may  throw  the  latches, 
on  another  hay  lie  may  set  the  dogbones,  etc.). 
This  is  a  form  of  teamwork  which  has  been 
labeled  a  Type  II  virtual  dependency.  It 
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sImiu til  be  Mis|)octcd  wlien  it  Is  believed  that 
every  leant  member  or  nested  team  member  knows 
Itow  to  perform  alL  the  individual  activities 
within  <1  set  of  activities,  and  when  it  is 
suspected  that  individual  assignments  to 
activities  are  not  given. 

.  Type  1  virtual  dependencies.  A  Type  I  virtual 
dependency  should  be  suspected  when  the  team 
members  or  nested  team  members  are  all  doing 
the  same  thing  (the  same  activity),  and  appear 
to  be  acting  individually.  The  primary 
example  is  providing  security.  A  given  team 
member,  When  providing  security,  is  not  only 
providing  security  for  himself,  but  for  others 
(who  are  also  providing  security).  Each  team 
member  is  dependent  upon  the  others  for 
security  or  protection.  This  is  indeed  a  form 
of  teamwork. 

*  Procedural  dependency  between  two  or  more  team 
members  who  are  performing  identical 
activities.  For  example,  when  laying  a 
tactical  minefield,  tlx*  laying  party  is 
assigned  the  responsibility  to  dig  holes  for 
mines.  Frequently,  there  are  four  or  five 
team  members  performing  this  activity. 
Typically,  the  members  of  the  laying  party  are 
not  assigned  specific  clusters  or  holes  to 
dig.  One  team  member  will  self-select  a 
cluster  causing  other  team  members  to  select 
other  clusters.  The  clusters  are  self- 
assigned.  A  specific  team  member  works  on  a 
cluster  that  another  team  member  is  not 
working  on.  They  continue  this  self-selection 
until  all  the  holes  are  dug.  There  is  a 
dependency  among  the  team  members  in  a  sense 
that  they  coordinate  among  themjelves  the 
assignment  of  clusters,  usually  without  verbal 
communication.  This  sort  of  dependency  is 
difficult  to  Identify  from  docuaientatton,  but 
you  should  ask  yourself  it  this  kind  of 
self-selection  exists.  . 

.  Another  dependency  which  is  easy  to  miss 

Involves  per formnnee  of  a  procedure  involving 
electronic  equipment  where  the  equipment 
performs  most  or  all  of  the  procedures. 
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f.  Wl»en  reading  the  documentation  you  should  also  take 
notes  on  when  external  dependencies  are  likely  to 
happen  during  the  mission.  An  external  dependency 
is  a  communication  or  the  transfer  of  a  product  from 
a  member  of  the  team  to  someone  outside  the  team;  or 
a  communication  or  the  transfer  of  a  product  from 
someone  outside  the  team  to  someone  who  Is  a  team 
member. 

Record  suspected  external  dependencies  in  your 
notes.  During  the  observation  phase  you  should 
verify  the  the  existence  of  these  suspected  external 
dependencies.  External  dependencies  should  be 
expected  during  the  following  segments  of  a 
mission: 

.  The  issuance  of  an  operations  order  to  the 
team  leader  from  the  next  higher  level 
leader  (from  the  team  leader's  immediate 
supervisor). 

i  , 

.  The  transfer  of  completed  products  or  proce- 
dures  at  the  end  of  the  mission. 

.  Status  reports  between  the  team  leader  and  his 
immediate  supervisor  during  the  mission. 

Thus,  external  dependencies  can  occur  at  any  time 
during  a  mission* 

g.  Ulien  reading  the  documentation,  it  will  not  always 
be  clear  if  a  mission  activity  Is  an  individual 
activity  or  a  team  activity.  If  you  cannot 
determine  this  from  documentation,  you  should  record 
in  your  notes  the  mission  activity',  with  a  phrase 
indicating  that  you  are  not  certain  if  the  activity 
is  performed  by  an  individual  or  by  a  team.  The 
exact  situation  can  then  be  determined  during  the 
observation  phase.  Experience  has  indicated  that 
the  following  mission  activities  can  be  either 
individual  or  team  activities: 

.  The  preparation  of  a  report  (e.g.,  a  target 
folder). 

.  The  lifting  and/or  carrying  of  objects  (e.g., 
tools,  construction  materials,  equipment, 
etc,). 

.  The  operation  of  equipment.  .  ' 
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.  The  loading  and  unloading  of  materials  from 
vehicles. 

.  The  measurement  of  dimensions  (e.g.,  using  a 
tape  measure  to  measure  a  bridge  structure). 

h.  Also,  while  reading  the  documentation  you  should 

record  in  your  notes  the  eq. ipment  used  by  the  team. 
You  need  not  be  ccncerned  at  this  time  with 
assigning  that  equipment  to  individual  team  members, 
just  record  the  equipment  required  or  used  to 
complete  the  mission. 

Because  note  taking  Is  so  important,  this  description 
method  contains  a  note  taking  guide,  called  a  documentation 
worksheet.  It  appears  in  Appendix  A  and  has  been  designed 
to  assist  you  in  analyzing  the  documentation,  as  well  as  in 
recording  information  about  teamwork  which  is  unclear  from 
the  documentation.  Tie  worksheet  need  not  be  used  and  is 
not  considered  part  of  the  formal  mission  description.  You 
are  free  to  take  notes  in  your  own  format. 

These  preliminary  activities  are  designed  to  help  you  plan  for  the 
observation  phase  of  tlie  mission  description  process.  By  following 
these  procedures  or  activities,  you  should  obtain  a  good  feel  for  the 
context  and  content  of  the  mission  that  Is  to  be  described.  It  has 
been  found  that  reading  about  the  mission  before  actually  observing  the 
mission  sharpens  the  observer's  awareness.  Observers  who  do  not  read 
about  the  missions  before  observation  tend  to  generate  mission  descrip¬ 
tions  which  are  less  complete  than  those  observers  who  carefully  read 
the  documentation  and  prepare  good  notes. 


Determining  the  Number  of  Observers 

You  now  need  to  determine  t»w  many  observers  will  be  needed  during 
the  observation  phase.  Your  understanding  of  ths  mission  and  your 
notes  (or  the  documentation  worksheet)  will  help  you  to  make  this 
decision.  The  following  guidelines  are  provided: 

1.  If  the  team  type  is  small  and  the  team  members  are  not 
organized  Into  nested  teams,  then  one  obsotver  can 
adequately  make  the  observation. 

2.  If  t!«  team  type  Is  small  (five  team  members  or  less),  and 
the  team  Is  organized  Into  at  least  one  nested  team  which 
performs  activities  simultaneously  with  the  larger  team,  It 
is  suggested  that  two  observers  participate;  one  observer 
for  the  nested  team  and  one  for  tiie  team  at  large. 


1. 


If  the  team  type  Is  of  moderate  size  (greater  than  five 
members,  hut  less  than  twelve),  then  two  observers  are 
suggested  regardless  of  the  extstence  of  nested  teams. 

h.  If  the  team  type  Is  large  (twelve  or  more  team  members), 
then  the  following  formula  should  be  used  to  determine  the 
number  of  observers: 

Number  of  observers  ■  Number  of  Nested  Teams  X  1.2 

Thus,  if  the  team  type  has  three  nested  teams,  then  the 
number  of  observers  required  is  3.8  or  approximately  4.0. 

These  are  estimated  numbers.  You  may  elect  to  adjust  the  estimate 
based  upon  your  understanding  of  the  mission  to  be  described 
(particularly  your  understanding  of  when  nested  teams  tend  to  perform 
simultaneously  with  other  nested  teams).  The  suggested  guidelines 
assume  that  one  observer  would  not  be  able  to  effectively  observe  two 
or  more  nested  teams  at  one  time.  If  the  nested  teams  perform  the  same 
activity  throughout  the  mission,  then  a  single  observer  would  be  able 
to  observe  the  nested  teams  by  devoting  part  of  his  or  her  observation 
time  to  each  nested  team.  This  is  only  effective,  however.  If  the 
nested  teams  do,  in  fact,  perform  the  same  set  of  activities  throughout 
the  entire  mission.  If  this  Is  tlw  situation  with  the  mission  your  are 
now  considering,  then  the  estimates  generated  by  the  guidelines  can  be 
cut  in  half. 


Pre-Observation  Activities 

After  completing  tlie  preliminary  activities,  you  are  almost  ready 
to  observe  the  mission  being  performed  by  the  selected  actual  team. 
Three  or  four  days  before  the  observation,  it  is  necessary  to  meet  with 
the  members  of  the  observation  team  (If  more  than  one  observer  is 
participating).  The  purpose  of  this  meeting  is  to: 

1.  Inform  the  observers  of  the  mission  to  be  described  and 
observed.  It  is  assumed  that  the  observers  are  familiar 
with  the  description  method,  but  have  not  yet  read  the 
documentation  describing  the  mission.  The  mission  should 
be  described  to  them  in  your  own  words.  Explain  to  them 
what  you  believe  tliey  will  see. 

2.  Request  dial  each  member  of  tin*  observation  team  rend  tiie 
documentation  that  you  have  already  rend*  Also  provtde 
them  witli  your  notes  or  the  completed  worksheet. 

3.  Assign  each  member  nf  the  observation  ecam  a  set  of 
observation  responsibilities.  Hake  sure  they  understand 
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wli.it  they  are  to  observe,  and  what  Information,  they  are  to 
gather.  Using  your  notes  or  tin*  completed  worksheet,  be 
sure  to  point  out  areas  of  the  mtsston  where  the 
documentation  has  failed  to  provide  sufficient  information 
about  the  kind  of  teamwork  Involved,.  It  is  important  that 
they  clearly  understand  what  they  are  to  observe  and 
record. 

The  observation  phase  is  the  most  important  part  of  the  mission 
description  procedure.  It  is  during  the  observation  phase  that  criti¬ 
cal  mission  data  are  collected.  After  the  observation  is  completed, 
the  data  gathered  is  recorded  on  a  set  of  forms.  The  completed  forms 
constitute  the  mission  description.  Thus,  it  is  important  to  plan  the 
observation  phase  carefully. 

The  authors  recommend  that,  during  the  observation,  hand-held 
tape  recorders  be  used  to  describe  the  mission,  or  record  Important 
information.  Paper  and  pencil  has  been  tried  and  found  difficult  to 
use  in  the  field  environment,  particularly  if  the  observer  Is  required 
to  move  rapidly  with  the  team  or  team  members.  Paper  and  pencil  also 
do  not  fare  well  In  inclement  environments  (precipitation,  high  winds, 
etc.).  Trying  to  complete  forms  during  observation  does  not  work.  It 
is  more  effective  to  take  notes  during  observation,  and  then  complete 
the  required  forms  from  the  notes.  Make  arrangements,  if  possible,  for 
hand-held  tape  recorders. 

You  should  plan  to  observe  tlie  mission  from  beginning  to  end, 
starting  with  the  operations  order  given  to  the  team  leader.  Fot 
observation  purposes,  a  mission  can  be  thought  of  as  containing  the 
following  phases  or  segments: 

1.  The  preparatory  phase.  This  includes  receipt  of  the 

ope rat  Ion  order  by  the  team  leader,  planning  performed  by 
che  team  leader  (l.e.,  tlie  decision  making  involved  in 
determining  how  tlie  mission  will  be  performed).  Issuing 
a  warning  order,  preparing  equipment  and  materials.  Issuing 
the  order,  -nd  rehearsals  (if  conducted).  . 

2.  execution  phase.  This  Includes  movement  to  the  location 
where  the  mission  is  to  be  perfdrmed,  unloading  of 
equipment ,  and  actual  conduct  of  the  mission. 

>  Terminal ion  phase.  This  Includes  reloading  equipment, 
movement  back  to  the  original  location,  and  tlie 
notification  of  mission  completion. 

All  phases  of  the  mission  should  be  observed  (but  not  necessarily  by 
all  the  observers).  Experience  indicates  that  it  is  difficult  to 
observe  all  of  the  preparation  phase.  Typically,  the  operation  order 
is  given  tor  tlie  team  leader  12  to  24  hours  before  the  actual  mission 
is  to  be  performed.  This  is  to  allow  the  team  leader  time  to  plan  the 
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mission  and  assess  the  status  of  his  equipment  and  personnel.  In 
practice,  it  is  reasonable  to  start  observation  when  the  frag  order  is 
issued  to  team. members  by  the  team  leader,  however,  the  team  leader 
should  bo  questioned  by  the  observer  to  determine  who  delivered  the 
operations  order  to  the  team  leader,  and  when.  If  at  all  possible,  the 
observer  should  determine  as  precisely  as  possible  the  content  of  the 
operations  order,  and  who  (if  anyone)  assisted  the  team  leader  in 
planning  tlie  mission,  if  tlw?  operations  order  is  not  to  be  observed. 


On-Site  Activities 


Before  tlie  actual  observation  of  the  mission,  the  following 
activities  should  be  performed: 

1.  Meet  with  the  actual  team  that  will  be  observed.  Introduce 
yourself  and  the  observation  ten*,  to  the  team  leader. 
Explain  the  purpose  of  the  observation  (e.g.,  to  a  obtain  a 

description  of  mission  _  ,  ,  which 

emphasizes  teamwork).  This  should  occur  at  least  an  hour 
or  so  before  the  mission  Is  to  begin;  the  day  before  the 
mission  is  even  better. 

2.  Request  that  the  team  leader  introduce  you  to  the  team  . 
members.  Count  the  number  of  team  members  in  the  actual 
team  and  record  the  number  in  your  observation  notes. 
Remember  the  assistant  team  leader's  name  and  face  (if 
there  is  an  assistant).  If  you  can  recognize  the 
participants  by  sight.  It  will  be  helpful  when  you  are 
actually  observing. 

3.  After  meeting  the  team  members,,  interview  the  team  leader 
(platoon  leader,  squad  leader,  etc.).®  You  should  obtain 
the  following  information: 

a.  When  and  how  the  operation  order  for  the  mission  was 
tjsued  to  the  team  leader,  and  who  issued  It.  What 
was  the  content  of  the  operations  order?  Be  sure  to 
note  that,  this  was  not  observed,  but  obtained  during 
an  Interview  with  the  team  leader, 
h.  When  and  how  the  warning  order  was  issued  by  the 

team  leader.  Determine  If  the  team  leader  gathered 
t l»o  soldiers  together  to  Issue  the  warning  order,  or 
if  the  warning  order  was  propagated  through  the 
team,  member  by  member. 


®You  should  be  sensitive  to  the  fact  that  the  team  leader  nay  still 
have  a  lot  of  work  to  do  to  prepare  for  the  mission. 
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c.  Who  planned  the  mission?  Who  decided  what 

activities  tlie  individual  team  members  would  be 
assigned? 

if  the  team  leader  lias  time,  have  him  explain  the  mission 
to  you.  More  specifically,  ask  him: 

a.  What  is  the  goal  of  the  mission? 

b.  What  are  the  ARTEP  standards  for  cotuple ting  the 
mission? 

c.  Does  the  mission  require  any  non-organic  support 
(e.g.,  the  use  of  indirect  fire,  etc.)? 

d.  Are  there  equipment  or  materials  the  team  is  missing 
or  doesn't  have  that  it  would  normally  have? 

e.  Is  any  equipment  malfunctioning? 

Record  the  information  given  to  you  by  the  team  leader. 
Again,  make  sure  that  you  identify  this  information  as 
being  provided  by  the  team  leader  and  not  observed. 

It  the  team  leader  lias  time,  ask  him  to  identify  the 
position  titles  of  each  team  member.  Record  the  informa¬ 
tion.  if  the  team  leader  does  not  have  the  time,  this 
Information  can  be  collected  when  the  mission  has  been 
completed. 


Taking  Notes  Puri ng  Jt he^  Observation 

By  the  time  you  finish  asking  the  team  leader  the  preliminary 
questions,  it  will  be  about  time  for  the  team  leader  to  issue  the  frag 
order  to  the  team  members*  From  this  point,  copious  observation  notes 
should  be  taken.  In  your  notes,  you  should,  try  to  capture  the 
following  details  of  the  mission: 

1.  General  Information  about  the  mission  including  mission 
goal,  criteria  for  mission  success,  environmental 
conditions,  every  situation,  and  equipment  deficiencies. 

.2.  A  terrain  map  portraying  the  situation  in  which  thp  mission 
is  conducted  and  locations  of  personnel  and  equipment. 

3.  Description  of  tlte  actual  team  structure,  including  team 
positions  and  MOS,  number  of  individuals  in  each  position, 
equipment  assigned  to  positions,  and  the  mission  function 
of  each  position. 


4.  Descriptions  of  nested  team  structures  (If  any  exist  In  the 

team),  including  tlie  ,  sizes,  and  functions  of  nested 

teams,  and  how  (and  vh:n>  nested  teams  are  formed  and 
disbanded. 

5.  Descriptions  of  ttie  sequences  of  individual  activities  of 
and  dependencies  among  team  members  and  nested  teams. 

The  following  paragraphs  provide  more  detail  on  what  to  look  for 
(cues  and  events)  during  the  mission,  and  suggested  ways  of  recording 
mission  events.  Following  these  suggestions,  procedures  and  sugges¬ 
tions  for  completing  Lite  mission  description  forms  are  provided: 

1.  Record  data  about  the  environment  in  which  the  mission 
occurs.  A  situational  map  should  be  drawn,  but  often  the 
best  you  can  do  In  the  field  is  to  note,  in  words,  the 
following  items: 

a.  The  type  of  terrain  (sandy,  rocky,  etc.). 

b.  Tito  location  of  trees  and  other  cover  (e.g.,  to  the 
right  nr  left  of  a  bridge). 

c.  The  distances  between  vehicles  and  troops,  the 
distances  between  individual  team  members,  the 
distances  between  buildings  and  landmarks  (e.g., 
track  is  concealed  400  meters  from  the  target 
bridge). 

d.  The  elevations  of  landmarks  (e.g.,  tree  line  vs 
road). 

e.  The  Location  of  troops  and  their  direction  of 
movement. 

Record  any  information  about  the  environment  which  you 
believe  would  help  you  to  construct  a  situational  map  ' 
later  on. 

'  r  1 

2.  Record  climatic  conditions  (e.g.,  rain,  high  winds,  fog, 
approximate  temperature,  time  of  day,  etc.). 

3.  Also  record  In  your  notes  any  discrepancies  between  the 
actual  nested  team  structure  and  the  nested  team  structure 
you  hypothesized  from  reading  the  documentation. 


When  observing,  you  should  record  notes  about  the  specific 
functions  performed  by  the  nested  teams  (if  a  nested  team 
structure  exists).  Briefly  record  the  assignments  given  to 
nested  teams.  In  your  notes,  try  to  capture  the  objective 
or  goal  of  tin*  nested  team.  Also  record  the  number  of 
soldiers  in  each  nested  team,  as  well  as  their  position 
titles. 
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For  each  nested  Loam,  do,  Lor  ml  no  ll  tlio  nested  team 
sLrtirluro  is  stable  or  changes  In  size  or  membership  as  the 
mission  progresses.  Also  record  when  the  nested  team  is 
formed  and  if  and  when  it  is  disbanded.  Clock  time  Is  not 
the  critical  dimension  here,  but  it  is  Important  to  record 
the  "when"  of  an  event  of  action  in  relation  to  other 
mission  event's.  When  a  nested  team  is  formed  or  disbanded, 
try  to  record  the  specific  mission  activity  which 
accompanied  the  formation  or  dissolution  of  , the  nested 
team. 

You  should  also  record  in  your  observation  notes  any 
information  which  would  help  to  clarify  misunderstandings 
from  the  documentation.  For  example,  if  documentation  is 
unclear  as  to  whether  a  certain  action  is  a  team  activity 
or  an  individual  activity,  you  should  clarify  the 
misunderstanding  in  your  observation  notes. 

The  most  critical  items  or  events  to  be  looking  for  are 
internal  and  external  dependencies  (i.e.,  teamwork). 

Recall  that  dependencies  are  events  in  the  mission  where 
one  team  member  is  dependjpnjt  on'  another  team  member1  for 
Input  that  allows  him  to  start,  continue,  or  complete  one 
or  more  of  his  individual  tasks.  Dependencies  are 
Identified  by  understanding  the  definitions  of  each 
dependency  type,  in  addition,  the  following  guidelines 
will  help.  You  should  suspect  a  dependency  when: 

a.  Two  members  of  the  team  communicate  with  each  other 
(a  verbal  communication  or  a  verbal  communication 
mediated  by  a  radio  or  some  other  equipment). 
Typically  these  are  easy  to  identify  and  observe. 
Verbal  dependencies  should  be  suspected  when  orders, 
directions,  or  instructions  are  given. 

b.  A  member  of  the  team  uses  hand  or  body  signals  to 
direct  another  team  member.  Hand  signals  and  body 
signals  are  also  easy  to  identify  and  observe.  If  ja 
hand  signal  is  observed,  be  sure  you  question  the 
team  member  using  tlx*  hand  signal  to  determine  if 
the  hand  or  body  signal  is  a  standard  hand  signal,  a 
team  hand  signal  (a  hand  signal  developed  by  the 
team  and  used  in  every  mission  performed  by  the 
team);  a  mission  specific  hand  signal  (a  hand  signal 
specifically  developed  and  used  only  during  the 
mission  being  observed).  Hand  and  body  signals 
should  be  suspected  when  a  vehicle  (boat,  track, 

■  etc.)  is  being  guided  into  position.  Hand  and  body 
signals  should  also  be  suspected  when  there  Is  troop 
movement,  and  the  troops  are  directed  into . position 
or  signaled  to  move  into  action. 


other  forms  of  non -direct  communication  are  evident 
(e.g.,  smoke^  signals,  light  signals,  audio  signals, 
(non-speech  1 ,  etc.).  Again,  question  the  user  of 
these  signals  to  determine  if  they  are  standard, 
team  specific,  or  mission  specific. 

Smoke  signals,  light  signals,  and  audio  signals  are 
typicalLy  used  to  signal  the  start  or  finish  of  some 
action  or  event  during  the  mission.  Dependencies 
involving  such  signals  can  usually  be  detected  by 
noting  the  signal  (e.g.,  by  observing  the  smoke). 

The  task  of  the  observer  is  to  note  the  signal  and 
associate  it  with  some  event  or  action  chat  is 
taking  place  (e.g.f  flanking  movement  of  a  fire 
team). 

Two  or  more  team  members  pass  or  transfer  a  product 
or  object  (e.g.,  a  mortar  round,  a  piece  of  equip¬ 
ment,  etc.).  Typically,  these  kinds  of  dependencies 
are  identified  by  first  noticing  the  product.  When 
an  observer  first  sees  an  object  or  product,  he  or 
she  should  suspect  that  the  object  or  product  will 
be  transferred  between  team  members,  and  they  should 
anticipate  the  dependency.  As  an  observer,  you  must 
he  alert  and  attentive  to  all  the  objects  that  you 
observe,  since  they  in  fact  may  be  involve  a  depend¬ 
ency  at  some  point  during  the  mission.  Do  not 
dismiss  any  object  from  being  involved  in  a  depend¬ 
ency  or  transferred  between  team  members,  regardless 
of  how  Incidental  the  object  might  appear.  For 
example,  the  object  might  be  a  piece  of  paper  or  a 
pencil.  All  objects  observed  during  a  mission  have 
the  potential  to  be  involved  in  a  dependency,  the 
potential  to  be  transferred  between  team  members. 

Although  it  is  true  that  not  all  products  or  objects 
that  are  transferred  between  two  or  more  team 
members  are,  in  fact,  product  dependencies  (for 
example,  handing  another  team  member  a  rifle  so  that 
one  team  member  can  use  both  hands  to  adjust  his 
splice  gear  is  probably  not  a  product  dependency) 
looking  or  observing  for  a  transfer  will  enhance 
your  aL'lity  to  identity  dependencies  and  teamwork. 

The  transfer  of  a  product  or  object  should  be 
suspected  when: 
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.  The  team  itself  is  manufacturing  or  making  the 
product  (e.g.,  wheni  a  charge  is  being  placed 
on  a  mortar  round). 


.  Equipment  and  material  are  being  loaded  or 
unloaded. 

.  Tools  are  needed  to  perform  the  mission  (e.g., 
shovels,  hammers,  chainsaws,  etc.). 

Two  or  more  team  members  are  engaged  in  an  acti' ity 
and  appear  to  be  uorking  together.  Typically,  this 
situation  involves  either  or  both  procedural 
dependencies  .and  virtual  dependencies.  During  tie 
observation,  you  need  not  decide  which  type  of 
dependency  is  involved.  Your  first  concern  is  to 
describe  the  observed  team  work  in  sufficient  detail 
that  the  type  of  dependency  can  be  determined  when 
the  observation  has  been  completed. 

These  types  of  dependencies  are  difficult  to  detect 
and  observe,  since  they  typically  do  not  involve 
verbal  communication  or  a  product  (object).  Two 
team  members  working  together  to  lift  an  object  can 
usually  be  detected  by  noting  the  object  and  not  the 
teamwork.  When  an  object  is  not  involved,  the 
teamwork  Is  more  difficult  to  identify.  For 
example ,  when  Installing  a  tactical  minefield,  the 
lasers  and  armers  stay  a  safe  distance  from  each 
other.  No  object  is  involved,  but  teamworn  is 
involved. 


only  a  little  guidance  Is  available  for  detecting 
these  forms  of  teamwork.  The  guidance  Is: 

observe  or  took  for  sequences  of  actions.  If 
you  notice  that  the  mission  has  a  definite 
sequence,  tlien  you  should  suspect  some  sort  of 
teamwork  among  those  people  ass  Lgned  the 
responsibility  to  perform  each  of  the 
sequences. 


be 
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Observe  or  look  for. one  team  me 
another  team  member  (e.g.,  one 
metal  stake  while  the  other  ha 
Into  the  ground).  These  might 
I  Ik*  observer  Is  looking  for  a 
object  (stake  and  hammer),  but 
he  Identified  by  observing  two 
together  or  two  |>eople  wl«>  nro 
space  or  area .  Witcn  two  or  mor<|! 
the  same  area,  you  should  suspe 
teamwork  or  dependencies.  You 
tlx*  area  and  observe  closely. 


tber  assisting 
oldier  holds  a 
rs  the  stake 
detected  if 
oduct  or  an 
:hoy  may  also 
icople  working 
n  the  same 
people  are  in 
it  some  sort  of 
should  move  to 


.  Observe  or  look  for  a  situation  where  a  group 
of  individuals  (or  a  nested  team)  has  been 
assigned  a  task  to  perform,  but  no  individual 
assignments  within  the  nested  team  have  been 
given.  Typically,  these  situations  require 
some  sort  of  teamwork  between  the  nested  team 
members  in  order  to  complete  the  nested  team 
assignments 

i  .  Observe  or  look  for  a  situation  where  two  or 

more  team  members  are  manipulating  or 
controlling  a  piece  of  equipment  or  a  large 
object.  For  example,  when  constructing  a 
ribbon  bridge,  several  team  members  (assembly 
I  section)  perform  a  set  of  activities  together, 

all  directed  toward  a  single  bay.  Often  they 
appear  not  to  he  working  as  a  team,  but  close 
>  observation  will  reveal  that  they  are. 

i 

f.  Two  or  more  team  members  arc  providing  security. 

I  Security  is  a  form  of  a  dependency  (teamwork),  and 

should  not  be  overlooked  because  no  products  are 
!  transferred.  Actually,  a  service  Is  transferred, 

;  hut  security  is  common  enough  to  be  called  out 

.  specifically  as  one  of  those  forms  of  teamwork  you 

)  sliould  look  for  and  record. 

I  Thus  whi  le  observing,  you  should  look  for  evidence  of  team- 

!  work.  More  specif ically,  look  for: 

i  a.  Two  or  more  team  members  conversing  with  each 

t  other. 

b.  Hand  signals  and  body  signals. 

c.  Smoke  signals,  light  signals,  or  audio  signals. 

J  '  d.  Objects  being  transferred  among  team  members  or 

nested  teams. 

'  e.  Team  members  working  in  toe  same  space  or  area 

(typically  this  Is  an  Indication  that  teamwork  is 

|  happening). 

i  f.  One  team  member  assisting  anotlier. 

g.  Tlie  provision  of  security. 

i 

h.  Occasions  where  team  members  appear  to  be  working 
individually. 
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i.  Occasions  whore  everybody  appears  to  be  doing  the 
same  thing. 

j.  Occasions  when  one  group  or  nested  team  must  perform 
a  set  of  activities  before  another  group  or  nested 
team  can  start  their  activities. 

If  you  observe  these  kinds  of  things  happening,  you  should 
immediately  suspect  some  sort  of  teamwork  and  move  closer 
to  observe  tlw  event  in  more  detail.  After  observing  the 
event  closely,  determine  if  there  dependencies  occur,  and 
record  their  occurrence. 

6.  After  Identifying  a  dependency  (teamwork),  what  information 
about  the  dependency  should  you  record  in  your  observation 
notes?  If  you  observe  what  you  believe  to  be  a  dependency 
(an  Instance  of  teamwork),  you  should  record  the  following 
items  about  the  dependency  in  your  observation  notes: 

a.  Tlie  Ini t in  tors  of  the  dependency.  Who  started  the 
dependency.  Do  not  record  names;  record  the  posi¬ 
tion  title’s  (squad  leader,  combat  engineer,  demoli¬ 
tion  specialist,  etc.).  If  two  or  more  positions 
have  the  same  title,  it  is  useful  to  distinguish  the 
positions  by  number  (e.g.,  rifleman  #1,  combat 
engineer  #6). 

h.  The  recipients  of  the  dependency.  Who  received  the 
communication,  the  product,  or  the  service.  Again, 
record  the  position  titles  of  the  recipients.  Be 
aware  that  there  may  be  more  than  one  recipient. 

c.  Hie  pattern  or  flow  of  the  dependency  (l.e.,  how  did 
tlie  product,  communication,  or  service  flow  from  the 
initiator  to  the  reclplent(s) ).  If  there  is  only 
one  recipient,  then  the  pattern  is  not  important. 
However,  if  there  Is  more  than  one  recipient,  the  ' 
pattern  Is,  important.  The  model  of  team 
per formance/bchnvior  suggests  several  patterns 
(e.g.,  fanout,  cluster,  propagation,  etc.)  You 
should  become  familiar  with  the  patterns  before  you 
begin  the  observation.  Tt  will  make  recording 
patterns  easier  If  you  can  use  one  of  the  pattern 
names.  Patterns  are  summarized  In  Figure  7  of  the 
model  In  Section  I. 

It  Is  not  essential  to  describe  the  patterns  here , 
since  they  are  adequately  described  in  the  model. 
However,  two  Important  aspects  of  dependency 
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patterns  will  be  intuit  toned  liere  to  refresh  your 
memory  wlien  recording  observation  notes.  These 
are : 

.  Almost  any  pattern  described  in  the  model  can 
take  on  the  form  of  a  "Z"  pattern.  In  your 
observation  notes,  it  is  important  to  identify 
the  pattern,  as  well  as  record  if  the  pattern 
assumes  a  "Z"  form.  A  ”Z“  pattern  or  forma¬ 
tion  occurs  when  the  recipients  of  the  depend¬ 
ency  communicate  back  to  the  initiator. 

For  example,  when  a  frag  order  is  given,  the 
recipients  may  ask  questions  of  the  initiator. 
Hits  makes  the  frag  order  dependency  have  a 
“Z“  pattern.  A  "Z”  pattern  should  also  be 
suspected  when  team  members  are  trying  to 
align  or  position  a  vehicle  using  hand 
signals. 

.  When  more  than  ore  recipient  is  involved,  it 
Is  important  to  note  If  the  recipients  receive 
the  dependency  as  a  group  (all  at  the  same 
time)  or  as  individuals.  This  distinction  is 
critical.  For  example,  when  a  warning  order 
is  Issued,  the  team  leader  may  call  all  the 
team  members  together  and  issue  the  order  in  a 
group  setting,  ov  he  may  "see"  each  team 
member  individually.  This  is  a  fanout  pattern 
In  both  cases,  but  it  Is  important  to  record, 
In  your  notes,  If  the  fanout  pattern  was 
Individually  or  group  structured. 

The  dependency  element  or  what  was' transferred. 
Describe  In  your  observation  notes,  exactly  what 
took  place  between  the  initiator  and  the 
rectpcnf(s).  For  example,  if  a  hand  or  body  signal 
was  given,  describe  the  hand  or  body  signal,  and  Its 
purpose.  Record,  if  possible,  if  the  signal  is 
standard,  team  specific,  mission  specific. 

If  a  verbal  communication  Is  given,  indicate  in  your 
observation  notes  the  content  of  the  communication 
(e.g.,  ll  you  observe  an  ope rat ten  order  being 
Issued,  you  should  record  the  content  of  the  order, 
such  as  the  purpose  of  tlx?  mission,  the  chain  of 
command,  the  enemy  situation,  actions  or  enemy 
contact,  location  of  other  friendly  troops,  etc.). 
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If  the  dependency  involves  the  transfer  of  a 
product,  record  the  product  that  was  transferred. 
Also,  describe  its  state  (e.g.,  “mortar  round  fused 
and  charged"). 

If  a  service  was  involved,  describe  the  service; 
e.g,  security  provided,  bay  assembly  completed,  etc. 
lie  as  detailed  as  possible  in  your  notes.  Describe 
the  service  as  precisely  as  possible.  If  the 
service  is  not  evident,  describe  the  actions  or 
events  you  believe  to  be  the  service. 

The  purpose  of  the  dependency.  Record  in  your 
observation  notes,  what  you  believe  is  the  purpose 
of  the  dependency.  The  liodel  of  team  performance/ 
behavior  contains  a  list  of  dependency  purposes. 

This  list  should  be  read  and  understood  before 
actually  conducting  the  observation.  It  should  be 
noted  that  any  given  dependency  can  have  more  than 
one  purpose. 

During  the  observation,  if  you  cannot  either 
remember  the  list  of  specified  dependency  purposes 
or  if  you  cannot , determine  the  purpose  from  the 
observation,  describe  Lhc  circumstances  surrounding 
the  dependency  in  as  much  detail  as  possible.  This 
will  help  you  later  to  determine  the  dependency 
purposes  which  are  applicable.  Record  the  context 
and  content  of  the  dependency  in  sufficient  detail 
so  that  later,  you  will  be  able  to  Identify  the 
purpose  or  purposes  of  the  dependency. 

Ihe  individual  actions  of  the  initiator  before  the 
dependency  was  initiated.  Describe  what  the 
initiator  was  doing  immediately  before  the  , 
dependency.  You  do  not  have  to  be  extremely 
detailed.  Typically,  a  single  phrase  will  suffice 
(e.g.,  providing  security,  measuring  the  physical 
dimensions  of  a  bridge  abutment,  etc.). 

Tltc  individual  activities  of  the  r»clplent(s)  before 
participating  In  the  dependency.  Again,  a  single 
phrase  should  bo  sufficient.  If  there  was  more  than 
one  recipient  and  each  was  Involved  in  n  separate- 
activity,  then  record  tin*  actions  of  each  recipient 
if  at  all  possible.  If  the  recipients  were  alL 
engaged  In  tlie  same  activity,  then  you  need  only 
record  the  activity  once. 
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h.  The  Individual  activities  of  the  recipient (s)  and 
Initiator  after  'the  dependency  has  occurred.  For 
example,  if  an  order  was  Issued  to  unload  a  vehicle, 
tlien  It  should  be  noted  if  Lite  reclpient(s)  started 
to  unload  the  vehicle. 

7.  In  addition  to  recording  the  occurrence  of  dependencies  and 
specific  dependency  information,  you  should  also  record,  in 
your  observation  notes,  the  use  of  any  equipment  that  you 
see  or  observe.  Libel  the  equipment  ns  best  as  possible, 
and  record  who  used  the  equipment  by  position  title  (e.g., 
"lensatic  compass,  squad  leader”).  If  you  have  the  time, 
also  record  how  the  equipment  was  used  (e.g.,  "lensatic 
compass — to  determine  azimuth  of  reference  points"). 

Taking  observation  notes  is  a  difficult  process.  There  is  a  lot 
to  remember  and  a  lot  of  information  to  be  recorded.  Your  first 
attempt  will  probably  generate  less  information  than  you  desire.  This 
will  become  evident  when  you  try  to  complete  the  forms  in  Step  4  from 
your  observation  notes.  However,  practice  will  Improve  the  quality  of 
your  notes.  As  you  learn  what  is  to  be  entered  In  the  required  forms, 
your  observation  notes  will  become  more  comprehensible  and  complete. 

A  job  aid  to  be  used  during  the  observation  phase  would  be  helpful  in 
this  regard.  However,  no  compact  Job  air  is  available  for  this 
purpose.  As  a  substitute,  the  following  is  offered.  The  priority  for 
collecting  observation  data  is: 

1.  Dependency  information  (initiator,  recipient,  pattern, 
element,  purpose,  and  individual  activities  before  and 
after  dependency). 

2.  Equipment  used. 

).  Nested  team  structure  and  function. 

4.  Documentation  uncertainties. 

5.  Environmental  data  (situational  map). 

6.  Night  or  day. (climate  conditions). 

If  you  notice,  the  tlrst  letters  of  each  category  are  DENDEN,  or  double 
DEN.  Hemoiiiber lug  double  DEN  might  help  you  when  you. first  start  taking 
observation  notes. 

The  most  difficult  part  of  tin*  observation  phase  is  identifying 
occasions  of  teamwork;  t.e..  Identifying  dependencies.  This  is  why  It 
is  extremely  important  to  carefully  read  the  documentation  before 
observing  the  mission. 


li  might  also  help  lo  realize  that  a  mission  can  be  divided  Into 
three  segments.  Identifying  these  segments,  as  well  as  remembering 
wliat  Is  likely  to  happen  In  each  segment  can  help  to  reduce  observation 
to  a  manageable  process.  Tlie  three  phases  are: 

1.  Preparation .  During  the  preparatory  phase,  you  should  look 
for  the  issuance  of  warning  orders,  operation  orders,  frag 
orders,  etc.  You  should  also  look  fw.*  the ‘ dependencies 
involved  in  preparing  equipment  and  materials  (e.g., 
loading  vehicles,  checking  equipment,  etc.).  Most 

,  preparation  phases  also  involve  external  dependencies. 

2.  Execution.  Tills  Is  the  "meat"  of  the  mission.  During  the 
execution  phase,  you  should  expect  to  observe  nested  teams 
being  formed,  team  members  within  nested  teams  working 
together,  nested  team?  working  together,  etc.  Execution 
phases  vary  widely  with  tiie  team  type  and  the  mission,  thus 
more  guidance  cannot  be  provided. 

3.  Disposition  or  Termination  Phase.  When  the  main  part  of 
the  mission  is  over,  typically,  most  team  types  engage  in 
some  sort  of  cleanup  activities.  You  should  expect  to 
observe  tlie  loading  of  equipment  and  materials,  the 
disbanding  of  nested  teams,  status  checks  on  equipment  and 
material,  etc.  You  should  also  expect  soma  external 
dependencies  Involving  the  team  leader.  Typically,  the 
team  leader  will  inform  his  superior  that  the  mission  has 
been  completed. 

Treat  each  of  the  three  segments  as  a  separate  observation  unit 
with  an  identifiable  beginning  and  end. 

Observation  Note  Cautions 

The  description  method  described  in. this  document  is  still. in  its 
infancy.  Thus,  not  ail  the  problems  associated  with  the  description 
method  have  been  resolved.  Most  of  these  unresolved  issues  impact  upon 
the  observation  phase,  and  the  recording  of  the  observation  data  on  the 
required  forms  (Step  A ) .  A  discussion  of  these  unresolved  Issues 
follows: 

1.  In  practice,  during  observation  of  a  mission,  more  than  one 
mission  might  be  observed.  Recently,  a  mission  performed 
by  Combat  Engineer  squad  was  observed.  Tlie  mission 
observed  was  labeled  "preparation  of  a  target  folder."  In 
reality,  the  major  part  of  the  mission  was  a  bridge  recon. 
During,  the  rerun,  data  were  gathered  for  entry  into  tlie 
target  folder.  Preparing  the  target  folder  itself  turned 
out  to  lx>  a  small  part  of  tlie  mission,  and,  Incidentally, 
turned  out  to  be  au  Individual  activity.  The  mission  was 
observed  from  tin*  moment  the  frag  order  was  Issued  to  the 
team  members  to  the  time  the  target  folder  was  completed  by 
the  squad  leader.  . 
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After  Lite  fra}>  order  was  Issued,  the  team  engaged  In  some 
preparatory  activities.  When  It  was  time  to  depart.  In  the 
APC,  the  first  set  of  activities  Involved  moving  the 
vehicle  from  Its  camouflage  netting.  This  Involved  a 
certain  amount  of  teamwork,  and  observers  recorded  the 
events. 

When  observers  returned  to  complete  the  mission  description 
forms,  a  debate  started — was  the  removal  of  the  vehicle 
from  the  netting  really  part  of  the  mission  or  ,was  it 
really  a  separate  mission,  according  to  the  ARTEF  manual? 

A  search  of  the  ARTEF  manual  revealed  a  Major  Mission 
Operation  title,  “Conduct  Unit  Movement  Operations.”  The 
removal  of  the  vehicle  from  camouflage  netting  was  not 
specifically  called  out  within  the  list  of  missions,  but 
could  conceivably  be  a  task  within  this  Major  Hisslon 
Operation.  It  was  decided  by  observers  that  this  activity 
was  a  separate  mission  and  this  segment  of  the  mission  was 
not  recorded. 


The  authors  cannot  suggest  a  way  to  easily  determine  that 
what  Is  observed  is  part  of  the  mission  you  set  out  to 
observe.  Only  familiarity  with  the  total  population  of 
missions  performed  by  the  team  type  would  help.  The  best 
practice  In  this  case  is  to  record  the  events  as  part  of 
the  mission,  then  check  the  AKTEP  manual  or  discuss  the 
matter  with  an  SME  upon  your  return  fro£  the  observation. 


2. 


In  practice  you  may  sec  a  repeat  of  the  mission.  For 
example,  in  the  bridge  recon  discussed  above,  two  bridges 
were  assessed  as  part  of  the  same  mission.  This  should  not 
bother  you,  since  It  provides  an  opportunity  to  verify 
observations.  It  Is  suggested  that  If  this  occurs  during 
observation^  that  you  treat  the  events  as  a  single 
mission. 


3. 


it  lias  not 
information 
important : 


peen  decided  if  it  is  important  to  collect  other 
For  example,  the  following  information  may  be 


a.  Dump  ton  of  the  mission  (start  time,  ending  time). 

b.  Number  of  times  tlx-  mission  has  been  performed  by 
the  team  observed. 


C  • 


The 

toge 


number  ol  mouths  or  weeks  the  team  has  been 
:her. 


d.  The  amount  of  turnover  In  the  team. 
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e.  'Whether  learn  members  have  boon  assigned  unfamiliar, 
or  novel,  responsibilities. 

At  this  time,  there  are  no  forms  on  which  to  record  this 
information,  but  as  an  observer  you  should  be  sensitive  to 
these  issues  and  record  these  k*nds  of  information  if 
observed.  It  is  expected  that  during  the  second  and  third 
years  of  the  effort,  the  importance  of  collecting  this  kind 
of  information  will  be  further  evaluated. 

Although  the  description  method  is  designed  to  record  what 
you  observe,  there  are  certain  practical  limitations.  If 
you  observe  two  team  members  communicating  with  each  other, 
and  you  hear  them  discussing  content  not  related  to  the 
mission,  should  you  take  observation  notes?  A  rather 
uncomplicated  response  is,  "No.”  However,  the  difficulty 
arises  in  deciding  what  is  mission  related  and  what  is  not. 
Obviously,  if  the  team  members  are  discussing  private 
matters,  then  the  conversation  is  not  mission  related. 
However,  interspersed  within  this  private  conversation  may 
be  examples  of  teamwork.  For  example,  one  member  says, 
"Hey,  we  better  hurry  up."  At  first  this  warning  may  be  , 
taken  casually  by  the  observer,  yet  this  dependency  may  be 
critical  to  mission  success.  There  are  no  specific 
guidelines  to  help  you  determine  what  is  and  is  not  mission 
.elated.  Record  In  the  observation  notes  anything  which 
you  believe  is  mission  related  with  the  hope  that 
non-mission  related  communications  can  be  screened  later. 
Your  judgment  on  this  issue  should  prevail. 

Luring  many  of  the  observations,  it  has  been  noted  that 
dependencies  are  often  supplemented;  e.g.,  an  initiator 
would  give  a  hand  signal  along  with  verbal  instructions. 
This  may  appear,  at  first,  to  cause  problems  for  the 
observer.  Should  the  observer  record  the  Instances  as  a 
hand  stgnal  dependency  or  a  verbal  dependency?  To  be  on 
the  safe  side,  indicate  that  both  verbal  and  hand  signals 
were  given  for  this  dependency. 

This  phenomenon  appears  to  happen  primarily  with  communica¬ 
tive  dependencies  (i.e.,  product  and  procedural  depend¬ 
encies  would  not  happen  together,  but  communicative  depend¬ 
encies  may  supplement  the  passing  of  a  product  or  complet¬ 
ing  a  procedure).  You  should  also  be  cautioned  that  it  is 
easy  to  miss  a  product  dependency  or  a  procedural  depend¬ 
ency  when  It  Is  supplemented  with  a  verbal  command.  Inex¬ 
perienced  observers  often  pick  up  the  verbal  communication 
(because  it  is  usually  obvious),  and  miss  the  transfer  of  a 
procedure  or  a  product.  It  is  easy  to  do.  Thus,  it  Is 


suggested  that  for  each  verbal  dependency  you  observe  ask 
yoursoll  — Is  there  anything  else  going  on  beside  tl»e 
transfer  of  words?  In  the  second  and  third  years  of  the 
current  effort,  more  specific  guidelines  for  this 
situation  wilt  be  developed. 

6.  The  last  unresolved  issue  pertains  to  identifying  depend¬ 
ency  recipients.  Often,  when  Instructions  or  Information 
arc  given  by  an  initiator  to  a  defined  set  of  individuals, 
others  can  hear  those  instructions.  The  question  is, 
"Should  these  'other*  Individuals  be  listed  as  recipients 
in  your  observation  notes?"  Practice  has  been  not  to 
identify  these  "others"  as  recipients*  It  has  been  assumed 
that  unintended  recipients  do  not  require  the  information 
to  perform  their  assignments.  Thus,  they  do  not  qualify  as 
being  part  of  the  dependency.  However,  It  is  supposed  that 
an  unintentional  recipient  might  eventually  use  the 
Information,  if  the  unintentional  recipient  uses  the 
Information  in  some  way,  then  the  recipient  has  indeed 
participated  In  the  dependency.  There  are  no  guidelines  to 
help  you  identify  those  situations  where  an  unintentional 
recipient  can  be  expected  to  become  a  legitimate  recipient. 
Again,  your  own  Judgment  should  be  used  In  this  situation. 

Every  problem  you  might  encounter  has  not  been  discussed.  If  you 
encounter  a  unique  problem,  it  is  suggested  that  you  consult  the  team 
performance/behavior  model  for  definitions  and  guidelines.  By  its 
definitions,  the  model  will  assist  you  in  thinking  about  a  problem.  If, 
the  model  does  not  assist  you,  then  the  recommendation  is  to  describe 
exactly  what  you  observe. 


Forms 

After  the  observation  is  over,  you  should  complete  the  forms 
associated  with  Step  A,  using  Information  from  the  following  sources: 

1.  The  observation  notes  (including  the  notes  gathered  during 
the  Interview  with  the  team  leader). 

2.  Tim  documentation  notes  (gathered  when  reading  the 
documentation ) . 

It  Is  strongly  suggested  that  you  review  your  notes  before 
completing  the  forms.  If  at  all  possible,  the  notes  should  be  reviewed 
no  later  than  24  hours  after  the  observation.  This  is  to  minimize  any 
forgetting.  In  addition,  the  forms  should  be  prepared  as  soon  as 
possible  after  observation. 


The  five  forms  associated  with  this  step  can  be  completed  In  any 
sequence.  Howe'er,  for  clarity,  they  are  discussed  in'  the  sequence  in 
which  they  wore  developed. 

Before  starting  the  forms,  you  may  elect  to  meet  with  your 
observation  team  aix'  make  individual  assignments  for  completing  the 
forms.  The  disunion  below  assumes  only  one  person  will  be  completing 
each  form.  Examination  of  the  sample  forms  in  Appendix  B  while  reading 
the  following  may  prove  useful. 


General  Mission  Information  (Form  3) 

To  provide  an  orientation  to  the  mission  that  Is  being  described. 
Form  3  was  developed.  The  reader  of  your  description  might  find  It 
useful  to  examine  Form  3  before  any  of  the  other  mission  specific  ; 
forms,  since  It  conveys  the  goal  or  purpose  of  the  mission.  The 
instructions  for  completing  Form  3  are  as  follows: 

1.  Complete  Blocks  1  through  6."  These  blocks  are  for 
recordkeeping  purposes,  and  will  help  you  keep  track  of  all 
the  forms  that  have  been  completed  for  the  team  type  and 
the  specific  missions  being  described. 

2. '  Enter  in  Block  7  a  statement  Indicating  the  goal. of  the 

mission.  When  you  interviewed  the  team  leader,  one  of  the 
questions  asked  was,  "What  Is  the  purpose  or  goal  of  the 
mission?"  Thus,  your  Interview  notes  should  be  useful. 

You  slmiild  also  consult  the  ARTEP  manual.  Typically  for 
every  Major  Mission  Operation,  there  is  a  brief  description 
of  tlx*  missions.  Tlie  missions  are  described  on  a  series  of 
dimensions.  Each  dimension  is  given  a  specific  title  or 
heading.  Under  the  title  "General  Standards"  of  the 
description.  In  formation  about  the  goal  of  the  missions 
wtthln  the  Major  Mission  Operation  is  given.  This  should 
be  read  before  completing  Block  7. 

3.  Enter  In  Block  8  the  criteria  (or  standards)  for  mission 
success.  The  ARTEP  standard  should  be  entered. 

4.  Enter  in  Block  9  any  known  conditions  which  Influenced  the 
performance  of  the  mission,  particularly  those  associated 
with  climate,  temperature,  etc.  You  may  also  want  to 
specify  the  enemy  situation  (e.g.,  was  the  enemy  in  the 
area;  did  the  team  expect  any  attack?).  If  NBC  gear  was 
used,  its  use  should  be  entered  In  this  block.  The  purpose 
of  this  block  Is  to  enter  any  Information  which  might  help 
the  reader  to  understand  the  mission,  .is  well  as  interpret 


GENERAL  MISSION  INFORMATION 


the  spec  it  Led  criteria  for  completing  the  mission.  Your 
oh  set' vat  ion  notes  will  he  helpful  here. 

5.  Enter  in  Block  10  the  non-organlc  support  the  team  required 
to  complete  tl»e  mission,  such  as  Indirect  fire  support, 
security  provided  by  another  unit,  etc.  Frequently 
vehicles  and  equipment  are  obtained  from  other  units.  Be 
sure  to  specify  all  non-organlc  support  noted  during  the 
observation.  You  may  also  want  to  check  the  ARTEP  manual 
frequently,  it  describes  the  kind  of  support  the  team 
might  require  to  execute  the  mission. 

6.  Enter  in  Block  11  any  assumptions  you  may  have  made  during 
the  observation  (e.g.,  it  Is  assumed  that  "X"  or  "Y”  Is 
part  of  another  mission,  and  although  observed.  Is  not 
described). 

7.  Enter  in  Block  12  any  other  information  which  you  believe 
the  reader  might  find  important  (e.g.,  equipment 
deficiencies,  the  experience  or  inexperience  of  the  team 
leader,  tlie  reason  why  the  ARTEP  standard  was/was  not 
achieved,  etc. ). 


Mission  Situational  Map  (Form  3A) 

In  order  to  orient  the  reader  to  the  mission,  a  situational  map 
is  constructed.  In  addition,  the  map  also  helps,  to  explain  or  describe 
the  observed  team  behaviors.  Form  3A  is  designed  to  provide  this  sort 
of  pictorial  representation  of  tlie  mission.  The  instructions  for 
completing  Form  3A  are  as  follows: 

1.  Complete  Blocks  1  through  6.  Enter  the  same  information 
(with  the  exception  of  BLock  3)  as  entered  in  Form  3. 

Enter  in  Block  3, the  sources  used  to  develop  the 

.  situational  map.  In  most  cases,  this  will  be  the 
observation  itself. 

2.  In  Block  7,  construct  a  sketch  of  the  mission  as  it  was 
observed.  The  sketch  should: 

a.  Use  standard  military  symbols. 

b.  1 1  Instate  troop  movement  (with  directional  arrows). 

c.  Indicate  the  location  of  trees,  roads,  bridges, 
brush,  and  other  landmarks  or  features. 

d.  Indicate  the  position  of  the  team  members  and/or 
nested  teams  in  relationship  to  other  team  members. 
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nested  teams,  vehicles,  and  landmarks  (e.g., 
buildings,  trees,  etc.). 

o.  Label  the  approximate  distance  between  team  members, 
nested  teams,  etc.  (Note:  Only  those  distances 
critical  to  the  mission  should  be  given). 

f.  Indicate  elevation  if  elevation  is  critical  to  the 
mission. 

g.  Show  the  location  and  movement  of  the  OPFOR  in 
relationship  to  the  team  being  described. 

h.  llLustrate  the  location  and  movement  of  vehicles.. 

1.  If  movement  of  troops  (Including  OPFOR)  is 

indicated,  attempt  to  associate  the  movement  with  a 
mission  activity  (i.e.,  when  during  the  mission  did 
the  movement  occur,  such  as  before  or  after  activity 

"X"  or  "Y"). 

It  may  be  necessary  to  draw  or  construct  more  than  one  sketch,  particu¬ 
larly  if  tlx-  mission  is  lengthy  or  if  there  is  considerable  movement  of 
troops  and  vehicles.  If  multiple  sketches  are  required  to  describe  the 
mission,  he  sure  to  label  each  sketch  (i.e.,  indicate  what  the  sketch 
describes). 

The  situational  map  entered  In  Block  7  need  not  be  precise  and 
accurate.  The  purpose  of  the  map  Is  only  to  provide  the  reader  with  an 
orientation  to  the  mission,  as  well  as  to  explain  possible  team 
■behaviors  (e.g.,  movement  «»t  nested  teams). 

Users  of  the  description  method  liave  also  found  it  convenient  to 
use  Form  3A  to  describe  specific  Items  (e.g.,  when  describing  some  of 
the  missions  performed  by  Combat  F.nglneers,  the  users  found  it 
convenient  to  enter  sketches  of  obstacles  constructed  In  Block  7)., 

These  sketches  were  a  supplement  to  the  situational  map.  The  item 
sketches  should  contain  dimensions  of  the  object,  as  well  as  plctorally 
represent  the  configuration  of  the  Item. 

Tlie  primary  source  for  tlie  situational  map  should  be  your 
observation  notes,  it  other  sketches’  are  provided;  e.g.,  a  detailed 
sketch  of  log  crib  or  a  minefield,  you  may  find  It  necessary  to  consult 
field  manuals.  It  Is  not  necessary  to  duplicate  any  sketches  provided 
In  field  manuals,  simply  reference  the  page  and  title  of  the  field 
•unual  where  the  sketch  can  be  located.  If  possible,  attach  a  copy  of 
tlw  sketch  to  Form  3A. 


\ 
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Actual  Team  Structure  (Form  4) 

It  is  necessary  to  document  the  structure  of  the  observed  team. 

Of  particular  importance  are  tlx?  position  titles  of  the  team  members, 
the  number  of  soldiers  having  each  position  title,  the  equipment  used 
by  the  position  title,  and  tlx?  functions  performed  by  the  position 
title  within  the  mission  being  described.  It  should  be  recalled  that 
Form  2  was  designed  to  record  similar  information  for  the  nominal  team 
structure.  Hy  comparing  Form  2  with  Form  4,  the  reader  can  determine 
if  the  actual  team  Is  under-  or  overslrength  and  has  the  necessary 
equipment. 

The  Instructions  for  completing  Form  4  are  as  follows: 

1.  Complete  Blocks  l  through  6  in  the  usual  manner.  Be  sure 
the  information  entered  is  identical  to  the  information 
entered  in  Form  3  and  Form  3A.  In  Block  3  enter  the 
sources  you  used  to  complete  the  form.  The  primary  source 
will  he  your  observation  notes. 

2.  In  Block  7  enter  the  position  titles  that  existed  in  the 
team.  Kntvr  tlx?  five  digit  MOS  code  and  grade  beside  the 
position  title.  If  you  are  not  sure  of  either  the  position 
title  or  the  MOS  code,  leave  them  blank,  but  be  sure  to 
complete  Blocks  8  through  10  for  the  unknown  position 
titles.  It  may  be  necessary  to  consult  Form  2  when 
completing  Form  4.  Form  2  should  contain  the  official 
position  titles. 

3.  In  Block  8  enter  the  number  of  individuals  i»ldlng  the 
corresponding  position  title.  This  may  he  difficult  to  do 
Iron  t he  observation  data.  However,  from  the  observation/ 
interview  data,  you  should  have  tlx*  total  number  of 
individuals  In  the  actual  team.  What  you  may  not  have.  If 
the  actual  team  Is  extremely  large,  is  the  way  the  total 
number  of  team  members  are  distributed  among  the  position 
titles.  If  you  do  not  know  the  number  of  individuals 
holding  each  position  title,  indicate  ’’unknown.” 

Be  sure  that  the  box  at  the  bottom  of  Block  8  contains  the 
total  number  of  team  members  of  the  actual  team  observed. 

4.  In  Block  9  enter  the  equipment  and  materials  you  observed 
the  jins  It  Ion  title  using.  If  two  or  more  team  members  have 
•  lie  same  position  title,  hot  are  using  different  equipment, 
separate  the  position  titles  with  identifiers.  For 
example,  suppose  the  team  observed  has  two  construction 
specialists  who  use  different  equipment  during  the  mission. 
Tlx?  position  titles  should  then  be  construction  specialist 
(l)  and  construction  specialist  (2).  Record  In  Block  9  the 
equipment  used  by  each  Identified  title  (e.g.,  construction 
special  1st  1 1 )  ). 
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Knter  only  the  equipment  observed  being  used  to  perform  the 
mission.  You  need  not  enter  individual  Issue  items  unless 
the  Item  Is  a  weapon.  if  a  tool  used  by  the  position  tttLe 
is  part  of  a  larger  col  loot l on  of  tools,  then  specify  the 
tool  and  the  collection  it  is  a  member  of  (e.g.,  hammer 
[from  carpenter's  tool  box]).  Only  the  end  user  of  the 
items  should  be  entered  (if  not  alL  the  items  ia  the 
carpenter's  tool  box  were  used  do  not  enter  the  carpenter's 
tool  box  as  a  piece  of  equipment). 

If  position  titles  share  a  tool  or  piece  of  equipment,  list 
the  item  for  both  position  titles,  but  Indicate  in  paren¬ 
thesis  that  it  is  "shared”  (e.g.,  hammer  [shared  between 
construction  specialists}).  Notice  that  if  equipment  is 
shared,  then  there  is  an  opportunity  for  product  or 
procedural  dependencies  to  occur  involving  the  equipment. 

Specifying  equipment  is  relatively  important  to  training. 
Often,  individual  training  and  team  training  revolve  around 
manipulating  equipment  and  tools.  Although  it  is  often 
difficult,  you  should  try  to  use  the  name  of  the  tool  as 
given  in  field  manuals. 

■>.  F.nter  in  Block  10  the  functions  performed  by  the  position 
title  during  tlx*  mission.  The  phrases  entered  should  be 
short,  hut  illustrative  (e.g.,  provides  security,  carries 
mines  to  minefield,  measures  bridge  structures  with  squad 
leader,  etc.).  It  the  position  title  Is  a  member  of  a 
nested  team,  this  should  he  indicated  in  Block  10  by  either 
grouping  positions  within  nested  teams  or  indicating  nested 
team  membership  with  letters.  Also  enter  tlx?  function  of 
the  position  title  within  the  nested  team.  Do  not  enter 
the  function  of  tlx?  entire  nested  team,  only  tlx?  function 
pertormed  by  the  individual  within  the  nested  team.  There 
Is  a  separate  form  for  recording  the  major  functions  of 
each  nested  team.  Be  sure  to  be  aware  of  the  possible 
existence  of  variable  nested  teams. 

If  a  team  member  performs  multiple  functions,  be  sure  to 
enter  each  function.  If  a  team  member  is  a  member  of. 
various  nested  teams,  list  all  nested  team  affiliations  in 
Block  l 0. 

A  typical  entry  can  bo  fairly  complicated  (q.g.,  "loads 
vehicles  with  other  team  members;  at  the  site  performs  the 
initial  mine  sweep;  after  mine  sweep,  joins  security  nested 
team  and  assumes  security  position  northeast  of  the  bridge; 
at  bivouac  site,  Ito.l  pn  other  team  members  to  offload 
vehicle"). 

Block  Id  will  typically  contain  Information  that  la  related 
to  teamwork.  In  fact,  Block  10  should  hlghLlght  the 
teamwork  the  position  title  engages  In  during  the  mission. 
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Block  10  should  provide  the  reader  of  your  description  with 
a  summary  of  tlte  Individual  and  team  activities  of  the 
position  title  (the  model  calls  this  a  "role  description"). 


Actual  Team  Structure  -  Nested  Team  Structure  (Form  4A) 

If  the  actual  Lean  observed  liad  a  nested  team  structure,  then  it 
is  Important  to  describe  the  nested  team  structure.  Form  4A  Is 
designed  to  record  nested  team  information  (e.g.,  the  number  of  nested 
team  members,  Lite  Lille  of  tlte  nested  team,  the  functions  performed  by 
the  nested  team,  and  Information  concerning  when  and  how  the  nested 
teams  were  formed  and  disbanded).  If  tlte  actual  team  you  observed  did 
not  have  a  nested  team  structure,  then  Form  4A  need  not  be  completed. 

Before  preparing  Form  4A,  your  observation  notes  and  documentation 
worksheet  should  be  carefully  reviewed.  If  the  actual  team  had  nested 
teams  which  were  stable  throughout  the  mission,  then  Form  4A  will  not 
be  particularly  difficult  to  complete.  However,  if  the  nested  team 
structure  was  variable.  Form  4A  can  be  time  consuming  to  complete. 
Notice  that  Block  lo  ot  Form  4  must  be  consistent  with  what  is  entered 
in  Form  4A;  i.e..  Form  4A  indicates  the  nested  teams.  Form  4  indicates 
what  position  titles  are  members  of  each  nested  team,  as  well  as  what 
function  each  position  served  within  the  nested  team.  If  nested  teams 
were  variable,  then  some  position  titles  had  changed  from  one  nested 
team  to  another.  Between  Forms  4  and  4A,  these  changes  should  be 
clearly  depleted. 

If  you  believe  you  liave  observed  variable  nested  teams,  then  it  is 
suggested  you  do  some  pre-planning  before  completing  Form  4A.  The 
following  activities;  should  bo  performed: 

1.  (hi  a  standard  sheet  ol  paper,  near  llie  left  edge,  list  all 
of  the  nested  teams  you  observed.  To  label  the  nested 
teams,  use  words  found  in  the  documentation,  or  If  the 
documentation  does  Hot  label  the  nested  teams,  construct 
your  own  labels  (e.g.,  security).  U6e  labels  which  are 
descriptive  of  the  function  performed  by  the  nested  team. 

2.  At  the  top  of  the  page,  list  each  member  of  the  larger 
team,  list;  short  descriptive  labels. 

3.  For  each  nested  team,  place  an  "X"  In  the  cell  of  each 
individual  whom  yoii  believe  was  a  member  of  that  nested 
team. 

4.  By  looking  down  the  column  of  each  team  member,  you  will  be 
able  to  determine  what  nested  teams  the  team  member  is 
associated  with.  If  a  teum  member  is  a  member  of  more  than 
one  nested  team,  then  a  variable  nested  team  structure  is 
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evident  and  one  of  several  situations  can  exist.  Either 
nested  teams  are  formed  and  disbanded  (allowing  the  nested 
team  member  to  become  a  member  of  a  new  nested  team  or  a 
member  of  an  existing  nested  team),  or  an  individual  is  a 
member  of  two  or  more  nested  teams  simultaneously.  The 
latter  has  never  been  observed,  except  where  a  team  member 
Is  a  supervisor  and  has  management  responsibilities  for 
several  nested  teams.  In  these  cases,  the  supervisor  is 
not  included  as  a  member  of  any  of  the  nested  teams  he 
supervises.  Thus,  If  tlx?  team  member  is  a  member  of  more 
than  one  nested  team,  you  must  determine  how  that  occurs. 
One  simple  explanation  Is  that  he  is  a  member  of  nested 
teams  which  do  not  perform  activities  simultaneously. 

You  should  check  your  observation  notes  to  determine  if  the 
two  or  more  nested  teams  perforin  within  the  same  period  of 
time.  If  they  do,  then  several  explanations  are  possible. 
These  are :  , 

a.  The  team  member  was  reassigned  to  another  nested 
team  sometime  during  tlie  mission.  This  should 
Indicate  some  sort  of  dependency. 

b.  Tlie  team  member  volunteered  himself  in  and  out  of 
nested  teams. 

In  either  case,  the  sizes  of  the  various  nested  teams  may 
change  during  tlie  mission,  and  this  is  important'  to  note. 
Instructions  for  recording  this  variability  are  provided 
below., 

5.  Continue  the  analysis  of  the  matrix  you  contructed  until 
you  have  a  complete  picture  of  the  size  of  each  nested 
team,  how  the  nested  teams  were  formed  and  disbanded,  when 
the  nested  teams  were  formed  and/or  disbanded,  etc. 

6.  Attach  the  matrix  to  Form  4A,  then  complete  Form  4A. 

Before  providing  the  instructions  for  completing  Form  4A,  some 
cautionary  notes  concerning  variable  nested  team  structure  are 
warranted.  During  a  recent  observation,  a  situation  arose  which  was 
almost  impossible  to  record.  The  mission  was  the  construction  of  a  log 
crib  by  a  platoon  of  over  30  team  members.  Tlie  team  was  not  genuinely 
organized  into  nested  teams.  Nested  teams  were  put  together  as  needs 
arose  (e.g.,  to  dig  post  holes,  to  carry  logs,  to  cut  timber,  to 
construct  tlie  log  crib,  etc.).  Nested  teams  wire  put  together  almost 
at  random — whoever  was  available  and  appeared  to  he  unasstgned  was 
assigned  to  a  nested  team.  Each  nested  team  was  temporary.  For 
example,  logs  were  carried  trom  a  dump  point  to  the  construction  area 
several  times.  Each  time  the  composition  of  the  log  carrying  nested 
team  was  different.  Because  of  tlie  size  of  the  team  involved  (a 
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platoon),  it  was  impossible  to  keep  track  of  every  team  member.  Thus, 
it  was  impossible  to  accurately  record  wIk>  was  a  member  of  each 
temporary  nested  team.  To  record  this  situation,  observers  simply 
listed  the  various  nested  teams.  They  approximated  the  size  of  the 
nested  team  (with  a  minimum  and  maximum  number).  In  addition,  they 
recorded  that  the  nested  teams  were  formed  upon  demand  and  quickly 
disbanded  when  the  immediate  need  was  over.  This  was  not  a  precise 
description  of  what  occurred,  but  it  did  convey  the  general  situation 
to  the  reader. 

The  instructions  for  completing  Form  4A  are  as  follows: 

1.  Complete  Blocks  1  through  6  in.  the  usual  manner,  .^emember, 
in  Block  3,  you  should  enter  the  sources  used  to  prepare 
the  form.  The  primary  sources  will  be  documentation  and 
your  observation  notes.  Be  sure  to  enter  exactly  the  same 
information  as  entered  In  Forms  3,  3A,  and  4. 

2.  In  Block  7,  enter  the  titles  of  each  nested  team.  If  the 
precise  titles  of  the  nested  team  are  not  known,  enter  a 
title  which  is  descriptive  of  the  nested  team  function. 

3.  In  Block  8,  enter  the  size  of  each  nested  team  (how  many 
team  members  composed  the  nested  team).  If  the  nested  team 
varied  in  size,  enter  the  smallest  and  largest  size 
observed.  Also,  enter  the  average  size  of  the  nested  team; 
the  size  the  nested  team  tended  to  have  for  most  of.  its 
existence.  It  Is  Important  to  list  the  size  as  variable, 
because  this  is  the  only  indication  to  the  reader  that  the 
nested  team  structure  was  variable  in  size. 

4.  In  Block  9,  enter  a  description  of  the  function  performed 
by  the  nested  team.  Bo  as  comprehensive  and  complete  as 
possible.  If  the  nested  team  performed  multiple  functions, 
be  sure  to  list  them  all.  You  may  also  find  it  convenient 
to  specify  the  phase  of  the  mission  in  which  the  function 
was  performed  (e.g.,  ** nested  team  performed  function  during 
preparation”). 

5.  In  Block  10,  enter  a  description  of  how  and  when  the  nested 
team  was  formed  and  disbanded: 

a.  Indicate  if  the  nested  team  structure  was  discussed 
during.  Mie  frag  order. 

b.  Indicate  liow  individuals  were  assigned  to  nested 
teams  (e.g.,  standing  operating  orders). 

c.  indicate  who  was  the  supervisor  of  the  nested  team 
(by  position  title). 

d.  indicate  when  the  nested  team  was  disbanded  (e.g., 
when  function  is  complete). 
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e.  Indicate  how  the  nested  team  was  disbanded  (e.g.,  no 
orders  given,  tlie  nested  team  disbands  when  the  work 
assignment  is  complete,  nested  team  leader  informs 
next  higher  supervisor  when  the  responsibility  of 
the  nested  team  has  been  satisfied). 


Mission/Tcam  Activity  Description  (Form  5) 

The  most  useful  mission  data  are  detailed  descriptions  of  the 
mission  activities  provided  by  Form  5.  Form  5  is  the  most  time  consum¬ 
ing  form  to  complete  in  the  description  process,  since  it  contains  a 
listing  of  mission  activities,  plus  a  description  of  the  teamwork 
involved  in  those  activities.  The  form  is  primarily  designed  to 
present  the  dependencies  that  occur  in  the  mission,  as  well  as  the 
sequence  of  those  dependencies.  In  addition,  the  form  presents  a 
description  of  each  dependency;  the  dependency  participants,  dependency 
pattern,  dependency  type,  dependency  element,  and  dependency  purposes. 

Before  completing  Form  5,  some  preliminary  activities  are 
required: 

1.  Carefully  review  your  documentation  and  observation  notes. 
You  must  have  a  complete  and  accurate  mental  picture  of  the 
mission  before  you  can  record  it  on  Form  5.  It  may  be 
necessary  to  review  your  notes  more  than  once. 

2.  If  you  have  a  nested  team  structure,  determine  whether  you 
want  to  describe  the  activities  of  the  team  at  large  (the 
entire  team)  on  Form  5,  or  use  a  separate  Form  5  for  each 
nested  team.  This  is  a  critical  decision.  Experience 
indicates  that  If  the  actual  team  is  small  and  has  nested 
teams,  it  is  more  efficient  to  record  the  activities  of  the 
entire  team  (include  tiie  activities  of  each  nested  team  on 
a.  series  of  Fo?a  5s).  If  the  team  IS  larger  or  has  three 
or  more  nested  teams,  it  is  more  practical  to  record  the 
activities  of  each  nested  team  on  a  separate  separate 
series  of  Form  5s.  This  decision  has  some  recordkeeping 
and  description  consequences.  If  it  is  decided  to  describe 
each  nested  team  on  a  separate  Form  5,  then  an  additional 
Form  5  will  be  needed  to  record  the  dependencies  that  occur 
between  the  nested  teams.  This  additional  Form  5  is  not 
needed  if  all  tlie  nested  teams  are  described  on  the  same 
Form  5,  since  between  nested  team  dependencies  will  be 
described  on  it,  as  well, 

3.  If  it  lias  been  decided  to  describe  each  nested  team  on  a 
separate  series  of  Form  5s,  then  you  have  another  decision 
to  make.  Should  you  describe  the  dependencies  between  the 
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nester,  teams  first,  or  describe  the  within-nested-team 
activities  first?  Experienced  describers  find  no  advantage 
one  way  or  the  other. 

4.  Depending  upon  what  approach  you  have  selected,  per fora  the 
following: 

a.  If  you  have  elected  to  describe  the  entire  team  on 
one  Form  5,  review  your  notes  and  documentation. 
Then,  on  a  worksheet,  record  or  list  the  team 
mission  activities  in  the  sequence  in  which  they 
occurred.  To  help  you  organize  the  list  of 
activities,  keep  in  mind  ttie  concept  of  mission 
pha  ses.  The  activities  should  not  be  described  in 
detail,  use  brief  phrases  (e.g.,  issue  frag  order, 
prepare  equipment,  load  vehicle ,  mount  vehicle, 
enroute  activities,  initial  on  site  activities  and 
orders,  establish  security,  etc.).  Use  phrases 
which  indicate  team  activities  and/or  dependencies. 
Be  sure  the  activities  are  in  their  proper  sequence. 
If  some  mission  activities  are  repeated,  note  this.  ' 

b.  If  you  have  elected  to  describe  the  activities  which 
.  occurred  within  each  nested  team  separately,  then 

prepare  a  worksheet  for  each  nested  team.  This 
worksheet  should  be  similar  to  the  worksheet 
described  in  item  £  above. 

c.  if  you  have  elected  to  describe  the  dependencies 
between  the  various  nested  teams  first,  then 
construct  a  matrix  of  nested  teams  titles.  In  the 
cells  of  the  matrix  indicate  which  nested  teams  have 
dependencies  with  other  nested  teams.  Briefly 
describe  the  between-nested-team  dependencies.  Use 
key  words  or  phrases.  This  is  similar  to  the  matrix 
developed  in  the  documentation  worksheet. 

After  completing  these  preliminary  activities,  you  are  ready  to  start 
completing  Form  5s.  The  instructions  for  completing  Form  5s  are 
provided  below.  Those  Instructions  are  appropriate  regardless  of  what 
approach  you  have  selected., 

1.  Complete  the  first  six  blocks  of  each  Form  5  Ln  the  usual 
manner.  Bo  sure  all  tlio  entries  are  identical  to 
previously  completed  forms. 

2.  If  the  team  has  a  nested  team  structure,  circle  "Y“  in 

.  Block  7;  otherwise,  circle  "N."  If  the  MY“  Is  circled, 
then  a  Form  4A  should  be  completed. 
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3.  In  Block  8,  check  the  most  appropriate  phrase.  This  block 
is  designed  to  communicate  your  decision  concerning  which 
approach  you  have  elected  (to  describe  the  activities  of 
each  nested  team  on  a  separate  Form  5  or  describe  the 
activities  of  the  larger  team  on  one  Form  5).  If  you  are 
describing  the  dependencies  between  nested  teams,  leave 
Block  8  blank. 

4.  If  you  checked  the  first  phrase  in  Block  8,  then  in  Block  9 
enter  the  name  of  the  nested  team  being  described. 

5.  Review  your  preliminary  worksheet  notes  (the  ones  developed 
before  starting  to  complete  Form  5).  Enter  the  first  team 
or  mission  activity  on  your  list  (e.g.,  platoon  leader 
issues  operation  order  to  squad  leader)  In  Block  10,  toward 
the  top.  The  phrase  should  be  more  descriptive  than  the 
phrase  in  your  worksheet  notes.  The  phrase  should  have  a 
subject  ("platoon  leader"),  a  verb  ("issues"),  and  an 
object  of  the  verb  ("operation  order").  For  clarity,  yon 
should  also  enter  any  informative  phrases  (e.g.,  "to  the 
squad  leader").  Remember,  the  phrase  must  provide  the 
reader  with  an  understanding  of  what  ts  going  on  in  the 
mission.  Enter  successive  mission  events  or  activities  in 
order  down  Block  10,  using  additional  Form  5s  as  required. 

6.  In  Block  11,  enter  a  label  at  the  top  of  each,  column 
Indicating  each  of  *:he  team  or  nested  team  members.  If  the 
form  is  being  used  to  describe  the  dependencies  between 
nested  teams,  enter  a  label  indicating  the  nested  team 
name.  For  convenience,  each  label  should  be  numbered.  If 
ther~  Is  insufficient  space  to  record  the  team  member’s 
title  or  the  nested  team  name,  record  the  titles  or  names 
on  a  separate  sheet  of  paper.  Number  them  from  one^  to  the 
size  of  the  team  or  to  the  total  number  of  nested  teams.’ 
Enter  in. Block  11  only  the  corresponding  numbers.  Attach 
the  separate  sheet  to  the  front  of, the  first  page  of  Form 
5. 

Block  11  only  contains  enough  space  for  an  11  member  team 
or  nested  team.  If  the  team  or  nested  team  you  are 
describing  has  more  than  11  members,  then  you  must 
construct  an  additional  parallel  series  of  Form  5s. 

Enter,  in  the  columns  of  Block  11,  the  participants  of  the 
first  activity  recorded  in  Block  10.  Identify  the 
Initiators  by  entering  an  “l"  in  the  appropriate  columns  * 
Identify  the  reciplent(s)  by  entering  an  "R"  in  the 
appropriate  column(s).  A  single  Individual  can  be  both  an 
initiator  and  recipient  in  a  given  dependency.  If  this  is 


the  case,  enter  in  the  appropriate  columns  ”1/R."  it 
should  Ik:  noted  that  in  external  dependencies  only  an  "I” 
or  "R"  will  be  entered,  but  not  both. 

7.  In  Block  12  enter  the  Information  necessary  to  describe  Che 
dependency.  Perform  the  following  activities: 

a.  Determine  if  the  dependency  Is  external  or  internal. 
External  dependencies  can  be  easily  identified. 

In  external  dependencies,  the  initiator  or  recipient 
is  an  individual  outside  the  team  of  interest. 

Thus,  in  Block  11,  the  columns  would  contain  only  an 
"R"  or  "1,”  but  not  both.  If  the  activity  being 
described  involves  an  external  dependency,  place  an 
"E"  in  Block  12. 


Determine  the  dependency  pattern  (the  flow  of  the 
dependency  element  from  the  initiators]  to  the 
recipient [s] ).  In  discussing  the  model,  several 
common  patterns  were  noted  and  defined.  Standard 
sketches  of  these  patterns  were  developed.  Examine 
the  dependency  under  consideration  and  attempt  to 
match  it  with  one  of  the  common  patterns. 

These  common  patterns  and  their  definitions  and 
sketches  are  illustrated  in  the  section  dealing  with 
the  model.  To  match  a  pattern,  simply  determine  the 
number  of  initiators,  the  number  of  recipients,  and 
how  the  dependency  element  flows  from  the  initiators 
to  the  recipients ) . 

If  you  cannot  match  the  observed  pattern  with  a 
standard  pattern,  then  you  must  sketch  the  pattern 
(i.e.,  a  standard  sketch  cannot  be  used).  To  sketch 
tlx*  observed  pattern,  simply  start  from  the 
initiator  and  draw  lines  with  arrowheads, indicating 
the  direction  the  dependency  element  flowed  to  the 
recipients.  It  has  been  our  experience  that 
non-standard  patterns  are  yery  rarely  needed. 

In  Block  12,  enter  the  sketch  of  the  pattern.  For 
example,  if  the  observed  pattern  is  a  fanout 
pattern  (one  initiator,  several  retipients,  several 
very  similar  dependency  elements),  then  in  Block  12 
enter  the  following  sketch: 


o 
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At  the  top  left  of  the  sketch,  enter  the  Initiator 
oL  the  dependency  as  a  number.  Use  the  number  of 
the  team  member  indicated  in  Block  11  (i.e.,  the 
number  corresponding  to  the  column  which  contains 
an  ”1"). 

Also,  indicate  the  recipients  on  the  top  right  of 
the  sketch  by  entering  the  numbers  of  the  columns  in 
Block  11  corresponding  to  those  who  are  identified 
as  recipients. 

Thus,  if  position  1  was  the  initiator  and  positions 
3,  4,  and  5  were  the  recipients  in  a  fanout 
dependency,  the  appropriate  sketch  would  be: 


Determine  if  the  dependency  followed  a  "Z”  format. 

A  "Z”  format  occurs  if  the  recipients  ask  questions 
of  the  Initiator.  For  example,  when  a  frag  order  is 
Issued  by  a  squad  leader,  the  team  members  might  ask 
specific  questions.  Although  the  pattern  is 
basically  a  fanout  pattern,  the  question  and  answer 
part  of  the  dependency  makes  the  fanoui.  a  "Z” 
format.  Almost  any  standard  pattern  can  have  ”Z“ 
format. 

To  indicate  a  "Z"  pattern,  enter  the  letter  “Z” 
after  the  initiator.  Thus,  in  the  example,  we  have 
been  using  a  fanout  "Z"  pattern  would  be  indicated 

as: 

1  LsJ - - ;< 

Determine  if  the  recipients  received  the  dependency 
elements  individually  or  as  a  group.  This  is 
particularly  important  in  fanout  patterns.  For 
example,  a  frag  order  can  be  issued  by  the  squad 
leader  to  all  the  team  members  at  one  time,  or  the 
frag  order  can  be  issued  to  each  individual 
separately,  but  approximately  within  the  same  time 
period,  in  either  case,  the  appropriate  pattern  is 
a  fanout  pattern.  However,  it  is  important  to 
specify  if  the  recipients  received  the  Information 
individually  ot  as  a  group.  To  specify  if  the 
fanout  was  group-oriented  or  individually-oriented, 
record  the  words  "group”  or  "individual"  at  the 


bottom  middle  of  the  sketch.  For  example,  a  fanout 
pat  Lem,  where  tin1  recipients  receive  the  dependency 
element  In  a  group,  would  be  recorded  as: 


Group 


An  alternative  Is  to  bracket  those  who  received  the 
dependency  element  as  a  group;  e.g., 

,  I-aL— ■ 

If  tlie  recipients  received  the  information  individu¬ 
ally,  the  situation  would  he  represented  as: 


There  are  occasions  where  some  individuals  receive 
the  dependency  element  as  a  group,  while  others 
receive  it  individually.  For  example,  in  the 
illustration  being  used,  if  the  team  members  3  and  4 
received  the  content  of  the  frag  order  as  a  group 
from  team  member  l,  while  team,  member  5  received  it 
individually,  then  this  situation  would  be 
represented  as: 

t  1./:! . 0.4 1*  .5. 

or  it  could  be  represented  as  two  separate 
pat  terns: 

lUI-ULAL-* 


T1k>  first  pattern  is  a  "Z"  fanout  with  two  recip¬ 
ients.  The  second  pattern  is  a  simple  pattern  with 
oik'  initiator  and  one  recipient.  Two  patterns 
should  be  used  to  represent  the  situation  only  if 
tin  patterns  are  different;  e.g.,  in  the  example 
given  above,  the  group  situation  involved  a  question 
and  answer  component;  thus,  a  " t "  format  is  not 
Indicated.  In  the  second  pattern,  there  was  no 
question  and  answer  period.  Thus,  a  "Z"  format  la 
not  indicated.  These  patterns  are  different,  and 
therefore,  two  separate  patterns  can  be  used. 
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Determine  the  dependency  type.  The  section  dealing 
with  tin*  model  of  team  .-performance  "and  behavior 
discusses  dependency  types. 

Select  a  dependency  type  which  you  believe  correctly 
represents  the  mission  activity  being  described. 

For  tlie  type  selected,  record  the  type  abbreviation 
in  the  appendix.  If  the  situation  involved  is 
consistent  with  the  definition,  then  the  correct 
type  lias  been  selected.  If  the  definition  does  not 
agree  with  your  specific  situation,  then  repeat  the 
process  until  a  suitable  type  is  found. 

Once  you  have  selected  the  most  appropriate  depend¬ 
ency  type  to  describe  the  situation  or  activity,  it 
must  be  recorded  in  Block  ,12.  Each  dependency  type 
has  a  code.  The  code  of  the  selected  type  is  • 
entered  at  the  top  right  of  the  sketch  (above  the 
recipient  identifiers).  In  the  frag,  order  illustra¬ 
tion,  the  content  of  the  frag  order  was  given 
verbally  to  the  recipients  (the  communication  was 
not  mediated  or  given  Indirectly  via  a  radio). 

Thus,  the  proper  type  is  direct  verbal  communcatlon 
(or  verbal  communication,  direct).  The  proper  code 
is  "CD."  The  code  would  be  recorded  in  the 
following  manner: 

CD 

j  i_z i_[3,  s  &  .a— « 

In  a  previous  section  It  was  noted  that  some  depend¬ 
ency  typ's  are  supplemented  or  paralleled  with 
another  dependency  type.  For  example,  a  hand  signal 
tor  an  Infantry  lire  team  to  flank  right  or  left  is 
often  supplemented  with  a  verbal  command;  l.e.,  the 
oral  command  is  given  at  the  same  time  the  hand 
signal  is  given.  A  review  of  the  dependency  type 
definitions  would  reveal  that  two  type*  of  depend¬ 
encies  are  appropriate  to  describe  the  situation 
(direct  vurbai  communication  and  standard  hand 
signals).  The  codes  for  these  are  CD  and  CM, 
respectively.  Thus,  the  situation  could  be  recorded 
as  follows: 

CD,  CN 


Notice  that  bach  dependency  types  are  recorded, 
separated  by  a  comma.  Multiple  codes  will  typically 
only  he  required  if  one  of  the  dependency  types  is  a 
verbal  communcatlon;  l.e.,  verbal  communications  are 
given  wlH<n  hand  signal  are  given;  when  products  ere 
transferred,  etc.). 
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Determine  the  dependency  element.  The  dependency 
element  refers  to  the  communication,  the  product, 
procedure,  or  service  that  was  transferred  during 
the  dependency.  Notice  that  dependency  elements 
correspond  closely  to  dependency  types.  For 
example,  in  a  product  dependency,  the  dependency 
element  is  a  product.  In  a  communicative 
dependency,  the  dependency  element  is  a  message.  In 
a  procedural  dependency,  .the  dependency  element  is 
the  completion  of  a  set  of  activities.  In  virtual 
dependencies ,  the  dependency  element  is  a  shared 
service  (such  as  security).  Thus,  examine  the 
identified  dependency  type.  If  it  is: 

.  A  communicative  dependency,  specify  the 

content  of  the  message  (e.g.,  if  a  frag  order 
is  given,  specify  the  content  of  the  order;  if 
a  hand  signal  is  given  indicate  what  the  hand 
signal  means). 

.  A  product  dependency,  specify  or  describe  the 
product  (e.g.,  a  charged  and  fused  mortar 
round).  Be  sure  to  specify  any  important 
characteristics  of  the  product. 

.  A  procedural  dependency,  specify  or  describe 
tlie  set  of  activities  that  are  completed 
(e.g.,  a  sited  minefield,  a  completed 
operational  check,  etc.). 

.  ■  A  virtual  dependency,  specify  or  describe  the 
service  or'  shared  activity  (e.g.,  security 
l>c  i  ng  provided  ) . 

Record  the  dependency  element  below  the  sketch  of 
tl*»  dependency  pattern.  In  the  frag  order  example, 
the  dependency  element  would  be  recorded  as 
follows: 

CD 

tl  ?,1 . -Ui.Ai-AJ.L-<< 

ELEMENT :  KKAG  ORDER  CONTAINED  THE  FOLLOWING  IN  FOR¬ 

MAT  ioN--PUKPO.SK  OF  THE  MISSION,  TIMK  OF  DEPARTURK, 
CHAIN  OK  COMMAND,  PASSWORDS,  FKIKNDLY  SITUATION, 
ENEMY  SITUATION,  WHAT  TO  DO  UPON  ENEMY  ATTACK, 
I  Nl)  I VI  Dll  Ah  ASSIGNMENTS,  REVIEW  OF  STANDING  OPERATING 
PROCEDURES  AND  SIGNALS ,  MISSION  APPROACH,  LENGTH  OF 
MISSION,  EQUIPMENT  STATUS,  CONDITIONS  OF  PERSONNEL, 
STATUS  OF  AMMO. 


1  "US  1  r’fffswm*’**'** 


Determine  the  purpose  of  the  dependency.  The 
section  containing  the  model  provides  a  list  of 
dependency  purposes  and  definitions'.  To  determine 
tlio  purpose  of  a  dependency,  the  context  of  the 
dependency  must  be  understood  (i.e.,  you  must 
understand  »/ny  a  frag  order  is  given;  why  a  hand 
signal  is  given;  why  a  product  is  transferfed , 
etc.).  Thus,  to  determine  the  dependency  purpose 
ask  yourself: 

"What  is  the  purpose  of  the  dependency  or 

teamwork?” 

Often  the  question  can  be  answered  by  reading  the 
description  of  the  dependency  element.  After  asking 
yourself  the  above  question,  examine  the  list  of 
dependency  purposes.  Read  each  purpose  and  ask 
yourself  if  this  purpose  is  appropriate  for  the 
dependency  being  described.  Record,  in  Block  12, 
each  purpose  that  is  deemed  appropriate.  Record  the 
identified  or  selected  purposes  at  the  bottom  right 
hand  side  of  the  sketch.  To  continue  the  frag  order 
example.  It  can  be  determined  that  the  frag  order 
has  many  purposes.  These  are: 

.  Orders,  Instructions,  and  directions  (e.g., 
time  Of  departure,  chain  of  command). 

.  Status  of  Individual  Activities  (e.g.,  making 
of  assignments). 

.  Status  of  Personnel  (e.g.,  who  Is  Injured). 

.  Status  of  Supplies  (e.g.,  number  of  ammo 
rounds). 

Status  of  Equipment  (e.g.,  working  condition 
of  M-16). 

Information  —Mission  Environment  (e.g., 
location  of  friendly  troops. 

.  Information — OPFOK  (e.g.,  enemy  location). 

Tlx*  codes  for  each  of  these  arc:  OID,  SIA,  SP,  SS, 
SK,  I  ME,  and  I  MO,  respectively.  The  purposes  would 
be  recorded  us  follows: 

CD 

i  Lid — 

Oil),  SIA,  SP,  SS,  SE,  IME,  IMO 
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Few  do pendenc  ios  have  ns  many  purposes  as  a  frag 
order.  Typically,  only  one  or  two  purposes  are 
enough  to  adequately  describe  the  situation. 

It  should  be  noted  that  dependency  purpose 
categories  are  scheduled  to  be  revised  during  the 
second  year  of  the  effort. 

Completing  Block  12  of  Form  5  Is  the  most  difficult 
activity  in  completing  Form  5.  There  is  a  lot  of 
information  which  must  be  entered.  A  summary  of  the 
substeps  involved  in  completing  Block  12  is  provided  in 
Table  4.  This  table  can  be  used  as  a  job  aid  when 
preparing  Block  12. 

8.  In  Block  13  enter  any  information  which  might  be  helpful  to 
the  reader  of  the  description  in  understanding  the  activity 
or  dependency.  For  example,  if  a  hand  signal  is  used  you 
may  want  to  describe  the  hand  signal  (such  as,  hand  signal 
was  flat  hand,  palm  out,  held  near  the  chest).  You  may 
also  want  to  describe  the  individual  activities  of  the 
initiator  and  recipient(s)  before  and  after  the  activity  or 
dependency  if  this  is  not  clear  from  the  description 
itself. 

9.  Repeat  steps  1  through  8  for  the. next  team  or  mission 
activity  on  your  worksheet  list.  Continue  this  process 
until  all  activities  are  described. 

Helpful  Hints  for  Completing  Form  5 

Experience  in  completing  Form  5  has  resulted  in  some  useful 
conventions  which  you  might  want  to  adopt.  These  ares 

l.  Although  only  a  selected  variety  of  team  types  have  been 
observed  to  date,  it  has  been  noticed  that  some  iqission 
activities  are  common  to  many  missions.  For  exaaple ,  most 
missions  involve  the  Issuance  of  orders.  The  lifting  and 
carrying  of  objects  recurs,  as  does  loading  and  unloading 
materials  and  supplies.  Because  of  the  commonality  of 
mission  activities,  the  authors  have  prepared  descriptions 
of  these  common  activities.  The  descriptions  discuss  the 
commong  mission  activities  and  provide  guidance  about  hoy 
to  record  these  in  Block  12.  For  convenience,  these 
descriptions  are  provided  in  Appendix  C. 

When  you  record  a  mission  activity  in  Block  10  of  Form  5, 
it  Ik  suggested  that  you  consult  Appendix  C.  Determine  if 
tlie  mission  activity  you  arc  about  to  describe  is. discussed 
in  the  Appendix.  If  It  is,  then  much  of  the  work  involved 
in  completing  Block  12  cun  be  minimized. 


Sunreiry  of  Instruct  lots  for  Oanple ting  Block  12 


Status  of  Block  12 


1.  Determine  If  mission  activity  involves 
an  external  dependency  or  an  internal 
dependency. 

2.  Determine  the  dependency  pattern 
(see  model  for  standard  patterns). 


If  ectemal  dependency,  enter  act  ~E T  in 
Blix:k  12.  If  internal  dependency,  enter 
nothing. 

Enter  sketch  of  dependency  pattern;  e.g.. 


3.  Identify  initiator  of  dependency 
(examine  Block  11  for  an  "l”). 


Enter  initiator's  rusher  cfesignatlon  cn 
sketch  of  dependency  pattern;  e.g.. 


4.  Identify  recipients  of  ckpendency 
element  (examine  Block  11  for  "Ks"). 


5.  Determine  if  pattern  has  “Z"  format. 


Enter  recipient's  lutber  designation  an 
sketch  of  dependency  pattern;  e.g., 

3.4,4  5 


If  question  and  answers,  then  Indicate  a 
"Z'  format;  e.g., 


6.  Determine  if  recipients  received 
dependency  element  individually  or  as 
a  fyoup., 


7.  Determine  dependency  tyjw  (see 


If  received  as  group  or  Individually, 
indicate  so  on  pattern: 

Qroup  =>  3,  4;  Individual  »  5 

This  can  also  he  represented  in  a  short¬ 
hand  manner.  Place  brackets  arrxnd  those 
who  received  the  dependency  element  as  a 
group;  e.g.,  the  following  sketch  is 
considered  equivalent  to  tie  above 
sketch: 

J  /.|  13.  Alt  5  <t 

Enter  appropriate  type  code;  e.g., 

CD 

1 1  zl  [3. 
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Table  5  (Cbntirarxi) 


Suiwary  of  Instructions 


_ _  Step _ 

8.  Describe  dependency  element  (i.e., 
describe  Uiat  is  transferred  from 
initiator  to  recipient(s). 


9.  Determine  dependency  |ur|*)se(s)  (see 
model). 


for  Completing  Block  12 

_ Status  of  Block  12 _ 

Enter  description  of  dependency  element 
below  sketch;  e.g.. 


(3) 


-  ELEMNT- 


FRAG  ORDER  ODNEAINED  THE  FOLLOWING 
INFORMATION — PURPOSE  OF  MISSION,  THE  OF 
DEPARTURE,  CHAIN  OF  CDEtftND,  PASSWORDS, 
FRIENDLY  SITUATION,  WAT  TO  DO  UPCN  ENEMY 
CONTACT,  IMJIVUXIAL  ASSIGMENTS,  REVIEW 
OF  STANDARD  CFERATHC  PROCEDURES  AND 
SIGNALS,  MISSION  APPROACH,  THE  OR  LENGTH 
OF  MISSION,  EqUIPFtOT  STATUS,  CONDITION 
OF  ffiRSONNEL,  STATUS  OF  AFM). 

Record  dependency  purpose (s);  e.g.. 


(0 


OLD,  SIA,  SP,  SS,  SE,  DE,  DO 
-ELEMOT- 

FRAC  ORDER  ODNIAINED  THE  IOLLOWING 
INFORMATION— IURPOSE  OF  MLSSION,  THE  OF 
DEPARTURE,  CHAIN  OF  (DEMAND,  PASSWORDS, 
FRIENDLY  SITUATION,  VIIAT  TO  DO  UPON  ENEMY 
CONTACT,  INDIVIDUAL  ASSICNFFNIS,  REVIEW 
OF  STANDARD  OPERATING  PHtXEDURES  AND 
SIGNALS,  MISSION  APPROACH,  THE  CR  LENGTH 
OF  MLSSION,  EqUIPFENT  STATUS,  (ENDITION 
OF  HTKSONNEL,  STATUS  OF  AMD. 


It  should  be  realized  that  Appendix  C  will  not  provide 
guidance  on  every  situation  you  must  describe.  However,  it 
does  discuss  those  mission  activities  which  are  likely  to 
be  repeated  in  tlie  mission  and/or  frequently  encountered. 


2.  Experienced  users  of  the  description  method  have  a  tendency 
to  attempt  to  "chain"  dependency  patterns  together.  For 
example,  suppose  team  member  1  issues  an  order  to  team 
member  2,  wtio  in  turn  issues  tlie  order  to  team  members  A 
and  5.  There  is  a  tendency  for  experienced  users  to  sketch 
the  dependency  in  this  fashion: 


1 


CD 

- > 

OID 


CD 

2  I  2  1  >1  « 

OID 


Although  this  is  acceptable  (because  it  can  be 
Interpreted),  it  Is  strongly  suggested  that  first  time 
users  avoid  chaining  dependency  patterns  together  until 
they  have  accumulated  a  fair  amount  of  experience.  It  is 
not  as  easy  as  it  looks,  and  often  times  you  can  uninten¬ 
tionally  misrepresent  what  you  have  observed. 

3.  If  a  single  member  of  the  team  is  engaged  in  a  given 

individual  activity  for. a  good  part  of  the  mission,  it  is 
reasonable  to  list  this  individual  activity  in  Block  10  of 
Form  5,  and  then  indicate  that  the  activity  continues  by 
placing  a  line  down  the  individual's  column  in  Block  11. 

The  line  should  continue  until  the  individual  changes 
activities. 

A.  Often  segments  or  sections  of  a  mission  are  repeated;  e.g., 
the  second  row  of  a  minefield  is  laid  exactly  like  the 
first  row.  There  appears  to  be  no  need  to  duplicate  these 
in  the  mission  description.  It  is  useful  to  bracket  those 
repeated  activities  and  note  that  the  bracketed  activities 
are  repeated  "X"  times. 

5.  It  is  often  helpful  to  explain  the  situation  you  are  trying 
to  describe  to  another  individual  familiar  with  the 
description  method.  Often  this  person  can  assist  you  in 
determining  how  to  exactly  record  the  situation,  this 
technique  is  particularly  useful  if  you  have  encountered  a 
situation  that  is  giving  you  difficulty. 


•4 


< 
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CONCLUDING  REMARKS 


Although  the  description  method  may  at  first  appear  to  be  over¬ 
whelming,  It  Is  not.  Experience  has  shown  that  the  first  attempt  can 
be  frustrating.  There  is  a  lot  of  information  to  record,  and  there  are 
a  lot  of  recording  guidelines  to  remember.  It  wilt  be  found  that 
practice  greatly  improves  the  situation.  This  report  has  attempted  to 
make  the  process  as  systematic  as  possible.  However,  every  mission  and 
team  type  is  to  some  extent  unique.  This  uniqueness  makes  it 
impossible  to  develop  a  process  which  is  rigid  or  mechanical. 

In  addition,  this  report  lias  attempted  to  alert  the  user  to 
possible  situations  which  might  be  encountered  and  to  suggest  possible 
recording  solutions.  This  desire  to  avoid  surprises  for  the  user  has 
resulted  in  a  detailed  complete  discussion  of  the  team  description 
method.  One  concern  Is  that  the  user  will  encounter  a  situation  not 
covered  or  discussed  in  this  document.  Failure  to  adequately  discuss 
possible  deviations  might  lead  the  user  to  either  disuse  the  descrip¬ 
tion  method  or  to  become  so  creative  in  recording  observed  team 
activities  that  the  resulting  description  would  not  be  readable  or 
interpre table  by  others.  One  objective  of  preparing  this  report  was  to 
avert  either  outcome. 

Although  this  document  coccalns  definite  procedures  and  recording 
conventions,  it  should  not  be  forgotten  that  the  purpose  of  the 
description  method  is  to  record  information  about  team  types  and  the 
missions  they1  perform,  which  renders  of  the  forms  can  understand  and 
use.  It  is  really  not^  so  Important  to  adhere  strictly  to  the  guide¬ 
lines  or  conventions  provided  herein.  Indeed,  the  important  criterion 
is  to  generate  team  and  team  mission  descriptions  whicih  others  can 
read,  understand,  and  use.  The  guidelines  and  conventions  were 
designed  to  assist  you  in  identifying  what  is  important  to  record  about 
the  team  type  and  the  missions  it  performs.  The  guidelines  should  not 
be  viewed  as  laws.  If  you  encounter  a  situation  which  dictates 
violating  the  conventions  or  guidelines  in  order  to  improve  the  clarity 
of  the  description,  ,  th*n  you  should  feel  free  to  do  so. 

A  final  note  to  th*  reader:  this  Description  Method  (and  its 
doubtless  more  refined  successors)  is  a  tool,  with  specific  projected 
applications;  Foremost  of  the  applications  Is  tlie  development  of  team 
training  programs  and  techniques,  and  team  performance  and  evaluation 
measures.  Since  the  Description  Method  is  to  be  widely  applied  in  the 
future,  it  must  be  flexible  and  adaptable.  The  Description  Method, 
again,  is  not  law,  it  is  a  tool  for  your  use,  which  can  be  modified  or 
adapted  to  suit  your  specific  needs. 


/ 


APPENDIX  A 


DOCUMENTATION  WORKSHEETS 


nOCUMF.NTAT  I  ON  WORKSIIKKT 


Team  Type:  _ _ _ _  Preparer: 

Mission  Title:  _  _  _ _ _ _ 

Sources: 


1.  Do  you  suspect  a  nested  team  organization?  _ Yes  _ No.  If 

Yes,  list  the  pested  team  names  and  the  number  of  team  members  in  the 
nested  team. 

Name  Size  Stable  Variable 


Also  indicate  if  the  nested  team  structure  i»  stable  throughout  the 
mission  or  is  variable. 


2.  If  a  nested  team  structure  exists,  then  enter  in  the  cells  below  the 
dependencies  you  expect  between  the  nested  teams  which  are  unclear 
from  the  documentation. 


Develop  a  matrix  for  each  nested  team  which  will  show  the 
dependencies  between  each  team  member  of  the  nested  team.  You  will 
have  one  matrix  for  each  nested  team.  Attach  the  matrices  to  this 
worksheet.  If  there  are  no  nested  teams,  develop  one  matrix  for  the 
entire  team. 

Below  summarize  the  dependencies  which  you  feel  require  careful 
observation. 


Record  below  when,  during  the  mission,  you  expect  external 
dependencies.  Identify,  if  possible,  the  initiator  and  recipient.. 

Mission  Activity  and  External  Dependency  Initiator  Recipient 


6.  List  the  equipment  used  by  the  team  (e.g.,  shovels,  weapons,  paper 
and  pencil,  etc.). 


TEAM  MISSION  LISTING  form  i 


AtVEf  f-  Hf,  a*rmt>***  n&M4*/l£D  A*AO*  &VIWS  Attach  ARTEP  Motion  Luting 

rites  x.it  4  A-/3,  tr  wh€  *Yfl 


TEAM  MISSION  LISTING  form  i 


Attach  ART  HP  Mission  Listing 


SQUAD/SECTION  TASK  INVENTORY 


UNIT  TRAINING 


COUiCIlVI 
T8  AININO 
•  IOINS 


UNII  ACHIIVIJ 
l(Vtl  ) 


UNIT  ACHIf  VIS 
tiVU  3 


UNII  ACMIIVII 
UVIt  I 


TOE 
S-US 
ENGR  BN 


TOE 
S-108 
CAV  ROT 


TOE 
5-127 
SEP  BOE 


- m - wj  min  IMO 

f  8  AININO  1  T8AININO  1  MOUCIINCT 

II VII  3  TASKS  J  IIVH  I  TASKS  J  108  COMBAT 

_ M _ M  8IADY  STATUS 

LOCATE  YOUR  UNTT  IN  THE  LIST  TO  THE  RTGHT  OK 
THIS  BLOCK.  HIGHLIGHT  ALL  DOTS/XS  THAT  FALL  w 
TN  THE  COLUMNS  BEI.OW  YOUR  UNIT.  THESE  HIGH-  W 
LIGHTED  DOTS/XS  REPRESENT  THE  TASKS  THAT  ARE  o  £  u  wlo 


i/i  <  w  uiw 

ASSIGNED  TO  YOUR  UNIT.  LEVEL  X  TASKS  APPLY  <2  w  ^  ^ 
ONLY  TO  UNITS  WITH  THAT  SPECIFIC  CONTINGENCY  p  >•  >  J  p 


MISSION. 


vs  >  w  >lvs 
Ullxlui  <lul 


o  a 
uu  w 
ui  cn  c/i 
1/1 

E-*  I-* 
a>  ?.  to 
JH7 

>SO 
<  5?  U 


1.  PERFORM  COMMAND  AND  CONTROL 
FUNCTION 


Conduct  radio  communications. 

Operate  in  an  electronic  warfare 
environment. 

2.  PERFORM  ADMINISTRATIVE  AND 
LOGISTIC  FUNCTIONS 

Supervise  operator  maintenance. 

4.  CONDUCT  SECURITY  OPERATIONS 

Camouflage  position  and  equipment. 
Defend  against  NBC  attacks. 

Defend  against  air  attack 
Request  and. adjust  fire. 

Secure  works  i  t  «*. 

Conduct  reconna i usance  patrol. 

React  to  enemy  contact  (Squad). 
Process  prisoners  of  war  (PWs). 
Conduct  c  ivi  1  .d  i  s  turbance  operations 
(Squad). 

Engage  targets  with  50  caliber 
machine  -gun . 

Engage  armor  targets  with  M72A  LAW. 

5.  PROVIDE  IN FORMAT  ION  AND 
INTELLIGENCE 

Submit  ini  ei I i genre  spot  reports. 
Conduct  reconnu i ssance  for  obstacle 
locations. 

Conduct  special  reconnaissance 
missions. 

Conduct  a  hasty  route  reconnaissance. 


333333333 
333333  33 
333333  33 


3  3  3  3  3  3  3  3  3 


3|  3  3 
3  3 
3 


3  3  3 
3  3  3 


3I  I3 

3 


3  3  3  3 
3 


o  f- 
OU.  u 
c/1  <  UJ 
oi  to 
u. 

C  >•  > 
vs  >  w 
w  x  u 


3  3  3  3  3 
3  3  3  3  3 
3  3  3  3  3 


3  3  3  3  3 


3  3  3  3|  3 
3  3  3  3 
3 


3  3 


3  3  3 


EQUIP  &  MAINT  SEC 


SOU  AD/SECTION  TASK  INVENTORY 


UNIT  TRAINING 

couicuvi 

TRAINING'  UNI?  ACHII  VIS  UNI?  ACMIIVES  UNII  ACHIEVIS 
•  COINS  CIVIC  3  CIVIC  }  Civil  | 

Moncin:? 

IO* COMtAf 
HAD?  STAIUS 

I.OCATF  yoitr  unit  in  the  list  to  the  r 1 01  it  of 

THIS  BLOCK.  HIGHLIGHT  ALL  DOTS/XS  THAT  FALL 
IN  THK  COLUMNS  UK  LOW  YdUK  UNIT.  THESE  HIGH¬ 
LIGHTED  DOTS/SX  REPRESENT  THE  TASKS  THAT  ARE 
ASSIGNED  TO  YOUR  UNIT.  LEVEL  X  TASKS  APPLY 
ONLY  TO  UNITS  WITH  THAT  SPECIFIC  CONTINGENCY 
MISSION. 

Conduct  bridge*  reconnaissance. 
Roconnoiter  assault  bridge  crossing 
sites. 

Conduct  river  reconnaissance. 
Reconnoiter  crossing  area. 

6.  CONDUCT  OBSTACLE  AND  DEFENSIVE 
OPERATIONS  (COUNTERMOBILITY) 

6-16  Disable  bridges. 

6-17  Crater  roads. 

6-18  Construct  barbed-wire  entanglements. 

6-21  Emplace  non-explosive  anti-vehicular 

obstacles. 

‘6-?fl  fnnsrrTtrr- booby  traps.  — . 

6- 37  *  Install  a  point  minefield. 

7.  CONDUCT  BREACHING  AND  CLF.AR1NG 
OPERATIONS  (MOBILITY) 

7- 3  Breach  obstacles  with  explosives. 


7-8 

7-9 

7-11 


H-5 

8-8 

8-20 


Employ  rite  combat  engineer  vehicle 
(CEV). 

Construct  combat  trails. 

Assist  in  the  assaul t  of  fortified 
positions. 

8.  CONDUCT  FIXED  BRIDGING  OPERATIONS 

Reinforce  luldge  with  pler/bent. 
Layout  Bailey  bridge  site. 

Reinforce  damaged  panel. 


5-19 

5-28 

5-29 

5-30 


TOE 
5-145 
ENGR  BN 


TOE 
5-108 
CAV  RGT 


Ml 


i|  1  I  1 

3  3  3  3  3  3 


COUfCTIVI 

TRAINING 

•COINS 


SOUAD/ SECTION  TASK  INVENTORY 

UNIT  TRAINING  |  _rof  I  toT“ 


UNIT  ACHtiViS 
IIVII  ) 


UNIT  ACHKVfS  UNIT  ACHItVSS 
leva  i  uva  t 


rof 
5-14*5 
ENGR  BN 


- m - Tg  MIN  THO 

TRAINING  1  TRAININO  1  RSOftCKNCT 

KVU  1  TASKS  J  ICVU  I  TASKS  J  FOR  COMIAI 

- M - M  RIAOT  STATUS 

LOCATE  YOIJR  UNIT  IN  THE  I.TST  TO  THE  RTCHT  OF 
THIS  BLOCK.  HOT  III.  I  GUT  ALL  DOTS/SX  THAT  FALL 
IN  THE  COLUMNS  BELOW  YOUR  UNIT.  THESE  IIIGII- 
LICIITFI)  DOTS/SX  REPRESENT  THE  TASKS  THAT  ARE 
ASSIGNED  TO  YOUR  UNIT.  LEVEL  X  TASKS  APPLY 
ONLY  TO  UNITS  WITH  THAT  SPECIFIC  CONTINGENCY 
MISSION. 
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5-108 
CAV  RGT 


o  u 

U  W  U1 
O  UVKO 

o  to 

to  C~  H 

CQ  7-.  CO 
>  iJ  M  X 

w  >  <  o 
u  <  X  u 


TOE 
5  127 
SEP  BDE 


O  It  U  W  >4 
•r>  -t  tu  to 
as  to  a. 
02  CO  H 

C  02  >  _l  IJ 

J3  >  W  >  C 

UJ  X  U<  bl 


10.  CONDUCT  FLOAT  BRIDGING 
OPERATIONS* 

10-20  Install  guyl incs. 

10-23  Construct  a  light  tactical  raft 


CONDUCT  HORIZONTAL  CONSTRUCTION 
OPERATIONS 


14.  CONI) 


CONDUCT  VERTICAL  CONSTRUCTION 
OPERATIONS 


14-6  Construct  a  lilting  device. 

17.  CONDUCT  FIELD  WATER  SUPPLY 
OPERATIONS 

17-2  Reconnoiter  potential  water  point  ’ 

*N0TF.:  If  the,  Bridge  Company/P  la  toon  is 

equipped  with  M4T6  equipment,  the  unit 
will  train  only  M4T6  related  tasks. 

If  I  In*  'Hr I  *!>*.*•  Company /P I  at  non  Is 
equipped  with  MAB,  the  unit  will  train 
only  the  MAB  tasks.  • 
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NOMINAL  TEAM  STRUCTURE  FORM  2 


GENERAL  MISSION  INFORMATION 


AM*  AWfr  WR«i,  »W*  *1 


ACTUAL  TEAM  STRUCTURE  form  « 


ACTUAL  TEAM  STRUCTURE  PQRM 4 A 

NESTED  TEAM  DESCRIPTION 


MISSION/TEAM  ACTIVITY  DESCRIPTION 


MISSION/TEAM  ACTIVITY  DESCRIPTION  b 


MISSION  TEAM  ACTIVITY  DESCRIPTION  forms 


MISSION/TEAM  ACTIVITY  DESCRIPTION  FORM  5 


MISSION/TEAM  ACTIVITY  DESCRIPTION  forms 


MISSION/TEAM  ACTIVITY  DESCRIPTION  forms 


MISSION/TEAM  ACTIVITY  DESCRIPTION  forms 
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DESCRIPTION  OF  COMMON  MISStON/TEAM  ACTIVITIES 


APPENDIX  C 


DESCRIPTION  OF  COMMON  MISSION/TEAM  ACTIVITIES 

This  Appendix  is  primarily  designed  to  be  a  reference  for  the  user 
of  the  description  method.  After  a  user  identifies  a  mission  activity, 
the  user  should  determine  if  the  mission  activity  is  common  enough  to 
be  included  in  this  Appendix.  If  it  is,  then  much  of  the  work  required 
to  complete  Block  12  of  Form  5  can  be  minimized,  since  this  document 
explains  how  the  mission  activity  should  be  described  and  recoraed. 

The  following  common  mission  activities  are  discussed  in  this 
Appendix: 

1.  Issuance  of  orders  to  team  leader  by  team-external 
person(s). 

2.  Issuance  of  warning  orders  to  team  members. 

3.  Issuance  of  operation  frag  orders  to  team  members. 

4.  Issuance  of  other  orders  (e.g.,  directions  or 
instructions). 

3.  Lifting  and  carrying  heavy  objects,  which  requires 
teamwork. 

6.  Loading  or  offloading  supplies  and  materials  from  a 
vehicle  as  a  team. 

7.  Aligning  or  directing  a  vehicle  into  a  specific  location. 

.  r 

8.  Two  or  more  individuals  preparing  a  report  or  form. 

9.  Providing  security. 

For  each  of  these  nine  activities,  the  fol lowing  are  presented: 

1.  A  discussion  of  the  variations  in  the  common  mission 
activities. 

2.  The  standard  pattern  that  should  be  used  to  describe  the 
dependency.. 

3.  Th<j  most  appropriate  dependency  type  to  describe  the 
activity. 


C-2 


[  'i  .  Til.-  cm;:  •  appropriate  dependency  purpose;,-  t<>  <lescribo  I  lie* 

i  art  i  v i  i  v. 

i 

5.  A  brief  discuss  ion  of  the  dependency  element. 

Most  of  t  tie  informat  ion  required  in  'i’oek  12  of  Form  S  is  discussed  for 
each  mission  activity. 


Issuance  of  Orders  to  Team  header  by  Team-External  Person(s) 


i 

! 

i 

t 


Variations  and  Patterns 

O-ders  are  typically  issued  at  the  beginning  of  a  mission.  Most 
frequently  the  order  involves  an  external  dependency.  An  individual 
outside  the  team  of  interest  will  give  the  order  to  the  team  leader 
(i.e.,the  leader  of  the  team  of  interest).  The  external  individual 
can  give  the  order  directly  to  the  team  leader  on  a  one-to-one  basis  or 
to  a  group  of  individuals  (of  which  one  member  of  the  group  is  the 
leader  of  the  team  of  interest).  These  two  variations  have  different 
patterns.  The  first  pattern  is  a  simple  pattern  with  one  initiator  and 
one  recipient  (the  leader  of  the  team  of  interest).  The  second  pattern 
is  a  fanout  pattern  with  one  initiator  and  multiple  recipients  (one  or 
whom  is  the  leader  of  the  team  of  interest). 


The  first  pattern  can  be  graphically  represented  as: 


K 


->  1 


U) 


where  the  "K"  denotes  an  external  dependency,  the  "X"  denotes  the 
initiator  is  an  individual  outside  the  team  of  interest,  the  single 
arrowhead  indicates  a  simple  pattern,  and  "l*'  denotes  that  the 
recipient  is  the  leader  of  the  team  of  interest. 

Tin*  fanout  pattern  can  be  represented  as: 

K  _xj _ Other  »  1  1 2 J  • 

when  the  "K"  denotes  an  external  dependency,  the  "X"  denote#  the 
initiator  is' an  individual  outside  the  team  of  interest,  the  double 
eager  \«)  indicates  a  fanout  |. alt ern,  and  the  phrase  "Other  ♦  l" 
denotes  that  others  plus  the  leader  of  the  team  of  interest  (designated 
1)  are  recipients  of  the’ order.  For  external  fanout  dependencies,  it 
is  not  necessary  to  specify  the  other  recipients,  only  those  who  are 
members  of  the  team  of  interest.  Titus,  if  two  members  of  the  team  of 
interest  received  tin*  order,  then  the  pattern  would  be: 

| _ Others  »  1  ,  2 


03 


K 


X 


(3) 


where  the  symbols  .ire  the  same,  except  the  phrase  "Others  +  .  L ,  2" 
denotes  that  included  in  the  set  of  recipients  was  team  members  "1"  and 
"2." 

If  the  order  involved  a  question  and  answer  dialogue  (assuming  the 
order  was  issued  verbally),  then  a  "Z"  format  would  be  indicated. 
Pattern  |1|  would  be  represented  as: 

.  E  X|  7.\ _ {  W 

where  the  symbols  are  the  same,  except  the  "Z"  denotes  a  "Z"  format.  A 
"Z"  format  would  be  indicated  where  the  recipients  are  permitted  the 
opportunity  to  ask  questions  or  clarify  the  orders,  and  the  initiator 
receives  ah  opportunity  to  respond  to  the  questions  or  clarifications. 
Pattern  [2]  would  be  represented  in  a  "Z"  format  as: 

E  X  [  Z  |  Others  ♦  1  [5J 

Again,  the  symbols  are  the  same  except  the  MZ'*  denotes  a  "Z"  format. 

Dependency  Type 

Orders  are  usually  given  verbally  and  directly.  Sometimes, 
orders  are  written  and  notes  presented  verbally,  and  often  they  are 
issued  both  in  written  form  (indirectly)  and  verbally  (directly).  If 
they  are  given  only  verbally,  then  the  proper  dependency  type  is  CD 
(Direct  Communication),  represented  as: 

E  jlLlI _ >  !  W 

If  the  order  is  only  given  in  written  form,  then  the  proper  dependency 
type  is  Cl  (indirect  Communication),  or: 

«  »1  i\ _ 1 _ .>  ,  i-i 

If  the  order1 is  issued  both  in  written  form  and  verbally,  the  most 
appropriate  representation  would  be: 

Cl,  CD 

k  jlLlL. _ _ _ _ _ >  j  181 

These  codes,  Cl  and  Cl),  can  also  be, used  with  pattern  [2|. 

Dependency  Element 

The  element  for  an  order  is  the  contents  of  the  order.  Typically, 
orders  contain  the  following: 

Objective  of  the  mission. 


1. 
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I  ssu.-inci;  of  Warning  ()rii>:rs  to  Team  Members 


Variat  ions  and  Patterns 

Warning  orders  are  issued  to  alert  the  team  that  they  will  be 
participating  in  a  mission  soon.  It  is  designed  to  communicate  a  "get 
ready"  stato.  Warning  orders  are  usually  issued  soon  after  the  ops 
order. 


Warning  orders  can  he  issued  in  a  variety  of  ways.  One  method 
observed  is  for  the  team  leader  (who  received  the  order)  to  issue  the 
warning  order  to  the  assistant  team  leader(s)  (say  team  member  number 
2).  The  assistant(s)  then  issue(s)  the  order  to  the  remainder  of  the 
troops.  This  is  by  no  means  the  only  way  warning  orders  are  presented. 
This  situation  can  best  be  represented  as  two  separate  patterns.  First 
the  passing  of  the  order  to  the  assistant: 


_Li 


->  2 


Ill 


where  "l"  denotes  the  initiator  (the  team  leader),  the  arrowhead 
denotes  the  direction  of  flow  and  a  simple  pattern,  the  "2"  denotes 
the  recipient  (the  assistant  team  leader).  If  the  pattern  has  a  "Z" 
format,  then: 


1  |  Z 


->  2 


[21 


The  "Z"  format  designation  would  indicate  that  the  assistant  asked 
questions  concerning  the  mission. 


The  second  pattern  would  indicate  tbit  the  assistant,  team  member 
2,  issues  the  order  to  the  rest  of  the  team.  This  would  be  represented 
as  a  fanout  pattern;  i.e.. 


2  1  Z 


N 


-« 


131 


where  the  "2"  indicates 
"Z"  denotes  a  "Z"  forma 
about  the  upcoming  miss 
"3  through  ll"  (where  N 
double  caret  (<<')  Honor 
s pec i f y  if  t he  as s i s t an 
group  or  i  ml  i vidua  I  I y . 
ally;  then  pattern  |3| 
the  order  to  some  team 
at  ion  should  be  used: 


the  initiator  is  the  assistant  team 
t  (only  needed  if  the  recipients  asked 
ion),  the  recipients  are  denoted  as 
indicates  the  last  team  member  number) 
os  a  fanout  pattern.  Pattern  [3}  neep 
t  issued  the  order  to  the  rest  of  the 
.  I f  each  member  was  issued  the  order 
is  proper.  However,  if  the  assistant 
member  as  a  group,  then  the  following 


jleader,  the 
questions 
am  members 
,  and  the 
s  to 

team  as  a 
iiiulividu- 
i s sued 
represent- 


2  I  Z  | 


HlJl 


Nj 


[4] 
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where  the  symbols  are  the  same  as  in  pattern  [3],'  except  the  brackets 
([))  around  the  recipients  indicate  the  recipients  were  gathered 
together  as  a  group  to  receive  the  order.  If  the  assistant  issued  the 
order  to  some  team  members  in  a  group  and  others  individually,  then  a 
different  sketch  would  be  required.  Those  recipients  who  received  the 
order  in  a  group  should  be  bracketed.  Suppose  team  members  3,  6,  and  7 
were  a  group  when  the  warning  order  was  issued,  and  team  members  4,  5, 
and  8  were  seen  individually  by  the  assistant,  then  the  most 
appropriate  sketch  would  be: 


It  should  be  noted  that  instead  of  two  separate  patterns,  the 
patterns  could  he  chained: 


The  first  part  of  the  pattern  represents  the  simple  flow  between  the 
team  leader  and  the  assistant,  while  the  second  part  of  the  pattern 
represents  far.out  pattern  between  the  assistant  and  the  rest  of  the 
team  members. 


Warning  orders  have  also  been  observed  as  being  issued  in  a 
propagation  pattern.  Here  the  team  leader  issues  the  order  to  the 
assistant  who  issues  it  to  the  next  team  member,  etc.,  until  all  team 
members  have  received  the  order.  The  correct  sketch  would  be: 


where  the  "l"  denotes  the  team  leader,  the  vertical  bar  (  |)  represents 
a  propagation  pattern,  and  the  team  members  receiving  the  order  and 
passing  it  to  the  next  team  member  are  represented  as  2,  3,  4,  '.  .  ., 

N.  Notice  i  le*  team  members  are  recipients  and  initiators.  The  team 
members  should  he  listed  in  their  observed  sequence;  e.g.,  if  "2" 
received  and  passed  to  "4,”  who  passed  to  "3,"  who  passed  to  "5,"  etc., 
thbn  the  correct  pattern  would  be: 


Note  that  the  "Z"  form  is  not  indicated.  Team  members  can  only  pass  on 
what  they  receive.  Questions  can  be  asked  of  the  initiator(s)  who, 
however,  cannot  adequately  respond.  The  place  where  a  "Z"  formation  is 
likely  is  between  the  initiator  and  the  first  recipient.  Tlius,  the 
iol lowing  representation  is  possible: 


Notice,  it  has  been  stated  that  warning  orders  can  be  issued  as 
fanout  or  as  a  propagation  pattern.  It  is  quite  possible  that  both 
patterns  can  occur  in  combination,  although  this  has  never  been 


observed.  Suppose  the  assistant  receives  the  order  from  the  team 
leader.  Further  suppose  the  assistant  informs  team  members  3,  4,  and  5 
as  a  group,  and  team  member  6  as  an  individual,  and  that  team  member  6 
informs  team  member  7  who  informs  8,  etc.  This  can  be  recorded  as 
separate  patterns.  The  first  pattern  would  describe  the  dependency 
between  the  team  leader  and  assistant: 

■I  Zj _ .>  ,  [101 

the  second  between  the  assistant  and  team  members  3,  4,  and  5  as  a 
group  and  team  member  6  as  an  individual  (the  fanout  pattern): 


2  I  2  1  [3,  4,  51  6  ,,  [111 

and  the  last  between  team  members  6  and  7,  and  so  on  (the  propogation 
pattern) : 

Q-J _ 2 ,  8 ,  •  ,  , ,  K  ^  {12] 

Patterns  (10],  [111,  and  [12]  can  also  be  combined  into  one  pattern: 


jlLlL 


“>  2 


2  1  (3,  4,  3]  6  „  I  7,  8, 


N  {131 


Dependency  Type 

Typically,  warning  orders  are  issued  verbally  and  directly'.  Thus, 
it  would  be  represented  as  CD  ( Common i,c at  ion  Direct).  Assuming  a 
propagation  pattern,  the  sketch  would  be  recorded  as: 

CD 

,  1  4,  9,  8,  7,  V  ....  U4 1 

Dependency  K  lenient 

The  content  of  the  warning  order  is  the  dependency  element. 

Typical  I y ,, the  warning  is  simple  and  straightforward  (e.g.,  We  have  a 

mission  to  _ ").  Also,  the  time  of,  the  mission  might  be 

given,  if  kniown. 

Dependency  Purpose 

The  purpose  of  a  warning  order  dependency  is  to  provide 
instructions  and  information  (01 1>) thus,  the  warning  can  be 
represented  as: 

CD 

,  I  2,  3,  5,  4,  <),  8,  7,  6  (15) 

01 D 

assuming  a  propagation  pal  tern. 
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Issuance  of  Operation  or  Frag  0 r d er  to  Team  Members 


Variations  and  Patterns 

Frag  orders  are  typically  issued  to  the  team  members  hy  the  team 
leader  shortly  before  the  mission  is  to  start.  The  most  common 
situation  is  for  the  team  leader  to  gather  the  team  members  together  as 
a  group.  Thus,  a  fanout  pattern  is  appropriate  to  describe  the 
situat ion : 

1  I  Z  |  [2,  3,  4,  5,  .  ,  .,  N)  „  [1] 

where  "1"  denotes  the  team  leader,  the  "Z"  denotes  a  format  (only 
required  if  questions  are  asked  by  the  recipient(s) ,  the  double  caret 
(<<)  denotes  a  fanout  pattern,  the  brackets  denote  the  frag  order  was 
issued  to  the  group  as  a  whole,  and  2,  3,  4,  5,  .  .  N  denotes  the 
recipients  of,  the  frag  order. 

One  'variat ion  of  this  is  also  seen  frequently.  Often  the  frag 
order  is'  issued  by  the  assistant  and  not  the  team  leader  (since  the 
team  leader  might  be  busy  doing  ether  things).  Thus,  the  pattern  would 
be  represented  as: 

2  I  Z  |  [_3_,  4,  5, ...  .  ,,  H)  _  ^  121  , 

It  should  he  noted  that  a  "z"  format  is  usually  needed  to  describe 
the  si tuat ion ,.  since  the  recipients  tend  to  ask  a  lot  of  questions 
about  their  own  individual  assignments,  about  what  to  expect,  etc. 


It  should  also  be  mentioned  that  in  missions,  the  team  leader  or 
Initiator  of  the  frag  order  also  talks  to  every  team  member 
individually  after  tin*  frag  order  is  issued  to  verify  that  each  team 
member  understands  his  assignment.  If  this  is  observed,  two  patterns 
are  required  to  describe  the  situation.  The  first  pattern  required  is 
the  issuance  of  the  frag  order  itself  (pattern  [l]),  the  second  pattern 
required  is  the  one  which  describes  the  individual  discussion  between 
the  team  leader  and  the  team  members.  This  can  be  represented  as  a 
simple  pattern  for  each  team  member;  e.g.. 


z  1 

'  1 

z ! . 

_u 

ll 

[31 


A  fanout,  pattern  is  not  appropriate  because  the  dependency  element 
transferred  between  the  team  lender  and  each  individual  is  probably 
different;  i.e.,  the  discussion  concerns  each  individual's  assignment 


nn<l  responsibility  in  tin*  mission.  As  .in  alternative  to  listing  each 
individual  dependency,  the  outward  cluster  pattern  can  be  used.  In 
fact,  the  outward  cluster  pattern  is  the  preferred  pattern  to  record. 
The  long  hand  version  of  the  outward  cluster  pattern  would  be: 


2 


where  "1"  denotes  the  initiator;  2,  3,  4,  and  5  denote  the  recipients 
and  E*  through  E^  denote  that  the  dependency  element  between  the 
initiator  and  recipients  are  all  different.1  The  shorthand  version  is 
as  follows: 

t  .  I  Z  |  2,  3,  4,  ...»  N  14) 

where  “l"  denotes  the  initiator,  the  "Z"  denotes  a  "Z"  format  (only 
appropriate  if  the  individuals  ask  questions  during  the  individual 
discussion),  the  single  arrowhead  denotes  an  outward  cluster  pattern, 
and  2,  3,  4,  .  .  .,  N  denotes  the  individual  recipients. 

It  may  be  elected  to  represent  the  issuance  of  the  frag  order  (the 
fanout  pattern)  and  the  verification  of  individual  assignments  (the 
outward  cluster  pattern)  as  a  chain  of  patterns;  e.g.. 


It  should  he  noted  that  the  verification  of  individual  assignments 
frequently  does  not  occur  on  an  individual  basis.  This  is  particularly 
true  if  the  team  of  interest  is  organized  into  nested  teams. 

Frequently,  the  team  leader  will  verify  the  responsibilities  of  the 
nested  team  as  a  group.  If  this  situation  occurs,  then  the  outward 
cluster  pattern  is  still  appropriate,  but  the  group  verification  must 
he  indicated  instead  of  the  individual'  verification.  Suppose  the  team 
has  one  nested  team  composed  of  team  members  4  through  N.  Further 
suppose  all  other  team  members  have  individual  assignments.  If  the 
team  leader  verified  the  responsibilities  of  each  individual  (individu¬ 
ally)  and  the  nested  team  as  a  group,  then  the  following  representation 
is  appropriate: 

,  -j  Z  i  2,3  [4,5,..;,  Nj  [6] 

where  "1"  denotes  the  team  leader,  "Z."  denotes  the  \’Z"  format,  the 
single  arrowhead  denotes  the  outward  cluster  pattern,  the  brackets 
indicate  the.  nested  team 1 (whose  responsibilities  were  verified  as  a 
group),  and  2  and  3  represent  the  team  members  whose  responsibilities 
■were  verified  individually.  An  alternative  representative  would  be: 


whom  the  "A"  denotes  the  nested  team  A,  composed  of  team  members  4 
through  N. 

Dependency  Type 

Frag  orders  are  typically  issued  verbally  and  directly.  Thus,  the 
proper  code  is  CD  (Communication  Direct)  which  can  be  recorded  as 
follows  in  the  fanout  pattern: 

CD 

!  I  Z  1  [2,  3,  4,  .  .  N)  ,,  [7] 

The  verification'  of  individual  asignments,  the  outward  cluster,  is  also 
usually  performed  as  a  verbal,  direct  communication  (CD).  Thus,  the 
proper  sketch  is: 

CD 

!  )  2  I  2»  3  (81 


Dependency  Element 


Notice  two  patterns  are  often  required  to  describe  the  issuance  of 
frag  orders.  The  fanout  pattern  to  represent  the  issuance  of  the 
order  and  the  outward  cluster  pattern  to  verify  individual  assignments. 
Each  of  these  lias  a  different  dependency  element. 

The  dependency  element  for  the  issuance  of  the  frag  order  is  the 
content  of  the  frag  order,  itself.  The  frag  is  a  "boiled  down"  version 
of  the  operations  order  and  usually  contains  the  following 
information: 

l.  Objective  of  the  mission. 


2. 

3. 


4. 


5. 


6. 

7. 

X. 


Tactical  approach1 
Status  of  equipme 
Status  of  supplie 


of  objective. 

[nt . 

s  and  Materials. 


Individual  assignments. 
Friendly  situation. 
Enemy  situation 


General  in  format i 
procedures,  meani 


on  and  direction  (e.g., 
ng  of  si  gun Is,  etc . ) . 


standing  operating 


Tlio  dependency  element  for  the  verification  of  individual 
assignments  consists  of  the  content  of  the  discussion  between  the  team 
leader  and  each  individual.  Thus,  there  are  as  many  elements  as  there 
are  individuals.  To  avoid  recording  all  of  these,  it  is  appropriate  to 
state  that  all  the  discussions,  in  general,  were  the  same  and  concerned 
the  individual's  assignment  for  the  mission. 

Dependency  Purpose 

The  purposes  of  the  frag  order  dependency  are: 

1.  Orders,  Instructions,  Directions  (OID). 

2.  Status  of  Individual  Activities  (SIA). 

3.  Status  of  Personnel  (SP). 

A.  Status  of  Supplies  (SS). 

5.  Status  of  Equipment  (SE). 

6.  Information  about  the  Mission  Environment  (IME). 

7.  Information  about  the  Enemy  or  OPFOR  (IMO). 

These  can  he  recorded  in  the  following  manner: 

CD 

1  |  Z  |  |2,  3,  A,  ....  Nj  '  [91 

Oil),  SIA,  SP,  SS,  SE,  l ME ,  IMO 

The  verification  of  individual  assignments  will  typically  have  the 
following  purposes: 

1.  Orders,  Instructions,  Directions  (OID). 

2.  Status  of  Individual  Activities  (SIA). 

3.  Feedback  or  Corrective  Action  (FC),  particularly  if  the 
individual  has  misunderstood  his/her  assignment. 

These  can  he  recorded  as  follows: 

CD  ' 

,  .1  /•  I  a.  »,  lA'I  .  1 10! 

1  OID,  SIA,  FC 
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Issuance  of  Other  Orders 


Variations  and  Patterns 

During  a  mission,  many  orders  are  usually  issued.  Soldiers  are 
given  instructions  and  directions  to  follow.  Typically,  these  orders 
are  issued  using  a  simple  pattern  or  a  fanout  pattern.  The  simple 
pattern  is  used  to  represent  the  situation  where  there  is  one  initiator 
and  one  recipient: 


The  fanout  pattern  is  used  when  there  is  one  initiator  and  multiple 
recipients,  and  the  dependency  element  transferred  to  each  recipient  is 
identical.  Typically,  the  order  is  given  to  an  entire  group  of 
individuals  or  a  nested  team.  Thus,  the  most  appropriate  pattern  is: 

I  U.  3.  M  ..  |2| 

where  "l"  denotes  the  initiator,  the  double  caret  (<<)  denotes  the 
fanout  pattern,  the  brackets  denote  the  order  was  issued  to  a  group  or 
a  nested  team,  and  the  numbers  within  the  brackets  indicate  the  members 
of  the  group  or  nested  team.  An  alternative  to  pattern  [2]  would  be: 


[3  J 


where  "A"  denotes  nested  team  A  composed  of  team  members  2  through  4. 

In  a  fanout  pattern  after  the  order  is  issued,  it  may  be  repeated 
by  the  nested  team  leader.  For  example,  in  an  Infantry  3qnad,  the 
squad  leader  may  issue  the  order  for  the  Alpha  team  to  flank  right. 
This  is  issued  to  every  Alpha  team  member,'  in  a  fanout  pattern,  in  a 
group.  Thus  sketch. [ 3}  above  is  appropriate.  Immediately  following 
this  order  from  the  squad  leader,  the  Alpha  team  leader  may  repeat  the 
order  to  his  team.  This  situation  can  also  be  represented  as  a  fanout 
pattern.  These . patterns  would  be  recorded  as: 


1 

2 


(A) 

f3,  4,  5, 


« 

6! 


« 


or  chained  together  as: 


(41 


.-^<2 — ti-A.-JuAU,  ni 

It  should  he  noted  fch.it  a  HZ"  format  is  not  indicated.  Typically 
in  a  tactical  situation,  the  recipients  d  ;ot^  have  an  opportunity  or 
time  to  ask  questions  about  the  order.  Thus,  a  "Z"  format  is  not 
usually  observed. 


/ 

/  / 


Although  simple  patterns  and  fanout  patterns  are  the  most  commonly 
observed  for  issuing  orders,  observers  have  encountered  a  rather  unique 
method  in  Infantry  squads.  This  method  is  common  to  many  of  the 
missions  performed  by  the  Infantry  squad.  In  a  movement  to  contact 
mission,  the  squad  typically  is  moving  in  a  wedge  formation.  The  point 
man  will  issue  an  order  using  a  hand  signal  (e.g.,  the  hand  signal  to 
stop,  danger  area).  This  order  is  then  transferred  down  the  wedge  from 
one  team  member  to  another  team  member  (all  using  the  same  hand 
signal).  This  situation  can  best  be  represented  using  a  propagation 
pattern,  such  as: 

3  I  lit  5,  6,  71  [8,  9,  10,  U]  [I,  2]  [6] 

where  the  "3''  denotes  team  member  3  (the  point  man),  the  vertical  bar 
denotes  a  propagation  pattern,  and  4  through  12  represent  the  recipient 
team  members.  The  brackets  denote  the  legs  of  the  wedge,  and  the 
sequence  in  which  the  hand  signal  was  propagated  (i.e.,  the  signal 
passes  from  3  to  4,  8,  and  l,  and  is  propagated  in  parallel 
thereafter). 

Dependency  Types 

Orders  issued  during  the  mission  are  typically  verbal  and  direct. 
Thus,  the  most  common  code  would  be  CD  (Direct  Cbmmunication) . 

However,  hand  signals,  smoke  signals,  etc.  should  also  be  suspected 
indicating  that  codes  Nl,  N2,  and  N3  may  be  possible.  N1  through  N3 
denote  the  use  of  signals  (Nl  denotes  standard  signals,  N2  denotes  team 
specific  signals  and  N3  denotes  mission  specific  signals). 

Dependency  Elements 

The  dependency  elements  will  .vary  depending  upon  the  ccntent  of 
the  orders . 


Dependency  Purpose 

The  purpose  of  the  dependency  will  vary  with  the  content  of  the 
orders.  However,  the  following,  purposes  should  be  suspected: 

1.  Orders,  Instructions,  and  Directions  (OLD). 

2.  Status  of  Mission  Progress  (SMP). 

^Oflen  the 'order  is  directed  to  the  Alpha  team,  but  is  also  heard  and 
understood  by  the  Bravo  team. 
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3.  Status  of  Individual  Activities  (SIA). 

A.  Feedback' or  Corrective  Action  (FC). 

5.  Status  of  Personnel  (SP). 

6.  Status  of  Supplies  (SS). 

7.  Status  of  Equipment  (SF,). 

8.  Information  about  Mission  Environment  (IME). 

9.  Information  about  Enemy  or  OPFOR  (IMO). 

,  Lifting  and  Carrying 


Variations  and  Patterns 


A  situation  frequently  encountered  is  the  lifting  and  carrying  of 
heavy  objects  by  two  or  more  team  members.  A  convention  has  been 
adopted  for  recording  this  situation.  It  is  viewed  that  lifting  and 
carrying  is  both  a  virtual  dependency  (Type  I)  and  a  procedural 
dependency  (P2).  It  is  a  Type  I  virtual  dependency  because  a  team  or 
nested  team  of  individuals  are  all  performing  the  same  activity  and  are 
dependent  upon  each  other  to  complete  the  objective  of  the  activity. 

It  is  a  non-mediated  procedural  dependency  because  complete  sets  of 
individual  activity  are  passed  from  one  team  member  to  another 
continuously  throughout  the  activity,  and  there  is  a  definite  sequence. 
To  record  this  situation,  use  the  following  sketch: 


V1/P2 


3,  4,  3,  6,  7,  8,  9 


III 


where  VI  denotes  a  virtual  dependency,  Type  I  (having  a  complex 
pattern),  3  through  9  denote  the  participants  in  the  lifting  and 
carrying  and  P2  denotes  a  non-mediated  procedural  dependency. 


Frequently  the  lifting  and  carrying  is  accompanied  by  a  super¬ 
visor,  who  is  not  involved  in  the  actual  lifting  and  carrying,  but 
issues  commands  and  '  ; admires  (e.g.,  "ready,”  "lift,"  "one,"  "two" 
etc;).  Thus,  an  additional  pattern  would  be  required  to  describe  the 
situation.  A  fanout  pattern  for  l|i«»  commands  and  cadences  is  required, 
plus  a  pattern  for  the  actual  lifting  and  carrying: 


3,  A,  r>,  6, 


VI/P2 


3,  A,  5,  6, 


7,  8,  9 


[21 


These  two  patterns  should  not  be  chained  together,  since  they  occur 
simultaneously. 
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Dependent' ' 


Tiie  command  cadence  pattern  would  have  type  code  of  CD  (Direct 
Communication).  No  code  is  needed  on  the  lifting  and  carrying  pattern, 
since  the  sketch  itself  contains  the  codes  for  virtual  and  procedural 
dependencies. 


Dependency  Element 

The  command  and  cadence  pattern  has  a  dependency  element 
consistent  with  the  commands  given  (e.g.,  "ready,"  "lift,"  "one," 
"two,"  etc.).  The  element  of  the  lifting  and  carrying  dependency  is 
simply  the  lifting  and  carrying  of  the  object.  However,  be  su^e  to 
specify  the  object  being  carried;  e.g., 

CD 

3,  A,  5,  6,  7,  8,  9 

l - 1 — — — -J — 2 - — « 

Element:  "Ready,"  "Lift,"  cadence  count  , 

3,  A,  5,  6,  7,  8,  9  , 

yl  - i - ! — > - » j ! - (P2) 

Element:  ’  Lift  and  carry  a  log  (10  feet,  1  foot  diameter) 


Dependency  Purpose  / 

The  purpose, of  the  command  cadence  pattern  is  typically  the 
provision  of  orders,  instructions,  and  directions  (OID).  The  purpose 
of  the  lifting  dependency  can  involve  the  following: 

1.  Status  of  Individual  Activity  (SIA). 

2.  Feedback  and  Corrective  Action  (FC). 

3.  A  stated,  nonstandard  purpose:  "carry  log  to  log  crib 
site." 


Loading  and  Unloading  a  Vehicle 


Variations  and  Patterns 

Three  variations  of  the  load i ng/un load ing  situation  have  been 
observed.  The  first  involves  a  team  or  nested  team  assigned  the 
responsibility  to  toad  or  unload  materials  and  supplies  from  a  vehicle, 
but  each  individual  is  not  given  a  specific'  assignment  and  all'  the 
items  are  portable  by  one  person.  Each  individual  continues  to  load  or 
unload  the  items  until  all  the  items  are  unloaded  or  loaded.  This 
situation  can  be  represented  by  a  complex  pattern.  In  addition,  the 
situation  fits  the  definition  of  a  Type  II  virtual  dependency.  Thus, 
the  most  appropriate  pattern  would  be: 

1',  2 ,  3,4,  5 ,  .  ...  N  I  i  ] 


where  V?  .iliMiMt  •*;:  .1  Type  il  virtual  dependency  .mil  the*  numbers  indicate 
the .  part  i  e  i  pant  s  in  the  loading  ami  tin  1  tt.nl  i  ng . 

Tin'  si'cnnd  variation  involves  the  loading  and  unloading  of  heavy 
objects;  e.g.,  logs.  Typically,  in  this  situation,  a  nested  team  is 
formed  at  random  and  assigned  a  position  on  the  vehicle.  Another 
nested  team  is  formed  (at  random)  and  is  assigned  a  position  off  the 
vehicle.  The  objective  is  to  pass  the  object  from  those  on  the  vehicle 
to  those  off  the  vehicle.  The  dependency  between  the  two  nested  teams 
can  be  represented  as: 


where  "A"  denotes  the  nested  team  on  the  vehicle  and  "B"  denotes  the 
nested  team  off  the  vehicle.  The  "7,"  format  is  indicated  because  there 
may  be  some  give  and  take  between  the  two  nested  teams.  It  should  be 
noted  that  the  dependency  between  the  two  nested  teams  is  not  a  virtual 
dependency.  It  is  a  non-mediated  procedural  dependency  (P2) .  It 
should  also  not  be  forgotten  that  there  are  dependencies  within  each 
nested  team.  The  within  nested  team  dependencies  are  probably 
adequately  described  by  pattern  f 1 |  in  the  Lifting  and  Carrying  Section 
of  this  Appendix.  The  two  patterns  can  be  chained  together  in  the 
following  way: 


where  the  first  set  of  brackets  denotes  nested  team  "A,”  the  second  set 
of  brackets  indicates  nested  team  "B,"  the  patterns  within  the  brackets 
indicate  or  describe  the  dependency  within  the,  nested  teams,  the  "Z" 
denotes  a  "Z”  format,  and  the  arrowhead  denotes  a  simple  pattern 
between  the  two  nested  teams. 


The  within  nested  team  dependencies  in  pattern  [3J  are  Type  II 
virtual  dependencies  and  need  not  be  coded.  The  between  nested  team 
dependency  is  a  procedural  dependency  (P2). 


Tin'  within  nested  team  dependency  has  the  element  of  transferring 
the  object  (e.g.,  fogs)  from  one  location  to  another.  The  between 
nested  team  dependency  has  an  element  concerning  the  transfer  of  weight 
between  the  "A"  nested  team  ami  the  "B”  nested  team. 


Dependency  Pur  pose 

The  within  nested  team  dependencies  have  the  following  purposes: 

1.  Status  of  Individual  Activities  (SIA). 

2.  Status  of  Supplies  (SS). 

3.  Feedback  and  Corrective  Action  (FC). 

The  between  nested  team  dependency  has  the  following  purposes: 

l.  StaLas  of  Individual  (nested  teams)  Activities  (SIA). 


2.  Feedback  anu  Corrective  Action  (FC). 


Aligning  or  Directing  a  Vehicle 


Variations  and  Patterns 

Three  variations  of  this  situation  have  been  observed.  The  first 
variation  involves  the  vehicle  driver  and  another  team  member.  The 
other  team  member  is  assigned  the  responsibility  to  give  hand  signals 
to  the  driver,  in  order  to  position  the  vehicle.  This  pattern 
typically  involves  a  "7'  format.  The  individual  directing  gives 
signals  one  at  a  time  until  the  vehicle  is  in  position.  The  driver 
reacts  to  each  signal,  and  in  response,  the  person  providing  the 
signals  reacts  to  the  driver’s  actions.  This  situation  can.be 
described  by  a  simple  pattern,  since  there  is  one  initiator  and  one 
recipient.  The  pattern  would  be  recorded  as:'  , 


where  "3'’  denotes  the  individual  providing  the  signals,  "Z"  denotes  the 
"Z"  format,  ''4*'  denotes  the  driver,  and  the  single  arrowhead  denotes  a 
simple  pattern. 

A  second  variation  was  observed  when  vehicles  without  rear  view 
mirvors  were  involved  and  the  vehicle  was  being  backed  up.  In  this 
situation,  a  team  member  is  positioned  to  the  rear  of  the  vehicle  and  a 
second  team  member  is  posit ioned  to  the  side  of  the  vehicle,  but  in 
iront  of  the  driver  in  the  vehicle.  The  person  to  the  rear  of  the 
vehicle  provides  hand  signals  to  the  person  at  the  side  of  the  vehicle, 
and  this  individual  in  turn  relays  the  hand  signal  to  the  driver.  The 
proper  pattern  to  represent  this  situation  would  be: 


3 


wit  or.*  "i"  iii'imt<*<i  I  Ik*  in.lividn.il  to  the  roar  of  tin*  vehicle,  the 
vi*rtii';i!  hnr  denotes  n  prorogation  pattern,  tin*  “Z**  denotes  a  ”Z” 
format,  the  person  to  the  side  ami  front  of  the  vehicle  is  denoted  as  4 
and  the  driver  is  denoted  as  5. 

A  third  variation  has  also  been  observed  frequently,  but  always 
appeared  to  he  ineffective.  This  is  a  case  where  no  single  individual 
was  assigned  the  responsibility  to  provide  the  signals,  and  as  a 
result,  the  driver  of  the  vehicle  would  be  receiving  signals  from  a 
group  of  individuals.  Frequently,  each  individual  would  provide  a 
different  signal.  This  situation  can  best  be  represented  as  an  inward 
cluster,  with  multiple  initiators  (each  with  perhaps  a  different  hand 
signal),  and  one  recipient — the  driver. 

Graphically,  the  variation  can  be  depicted  as: 

V  S.V* _ >  8  131 

where  1,  4,  5,  and  6  denote  the  position  numbers',  the  initiators  of  the 
hand  signals;  the  arrowhead  denotes  an  inward  cluster  pattern;  and  8 
denotes  the  position  number  of  the  driver  (recipient). 


Dependency  Type 

Regardless  of  which  pattern  is  observed  (the  simple  pattern,  the 
propogation  pattern,  or  the  inward  cluster  pattern),  the  dependency 
type  is  always  81  (standard  hand  signals). 


Dependency  Element 

The  dependency  element  consists  of  the  hand  signals  issued  during 
the  alignment  process.  It  is  not  necessary  to  list  the  hand  signals  in 
the  sequence  in  which  they  were  observed.  However,  it  is  necessary  to 
describe  each  hand  signal  that  was  observed. 


Dependency  Purpose 

Alignment  of  a  vehicle  into  a  prescribed  location  has  the 
following  purposes: 

1.  Orders,  Instructions,  Directions  (OID). 

2.  Status  of  Individual  Activities  (SIA). 

3.  Status  of  (equipment  (Vehicle)  (SK). 

4.  Feedback  and  Corrective  Action  (FC).. 


Variations  and  Patterns 

Only  two  variations  of  this  situation  or  mission  activity .have 
been  observed.  In  each  variation  only  two  people  or  individuals  are 
involved.  In  the  first  variation,  one  individual  obtained  the  data  to 
be  recorded  and  verbally  transmitted  it  to  another  individual  who 
recorded  it.  tn'lhis  variation,  the  data  gathering  was  performed  as  a 
team  activity  with  the  data  recorder.  The  form  completing  activity  is 
represented  by  the  following: 


whe're  "1"  denotes  the  data  gathering  and  transmission,  "Z"  denotes  a 
"Z"  format,  "2"  denotes  the  data  recorder,  and  the  single  arrowhead 
denotes  a  simple  dependency  pattern.  The  "Z"  format  is  indicated  to 
represent  the  back  and  forth  dialog  between  the  two  team  members. 

The  second  variation  involves  two  individuals  who  arbitrarily 
decide  to  divide  the  labor.  One  individual  takes  part  of  the  form  to 
complete,  and  the  other  individual  takes  the  remaining  part.  This  also 
can  he  represented  as  a  simple  pattern: 


The  "Z"  format  is  indicated  because  often  the  two  members  discuss  what 
should  be  entered  on  the  form. 

Notice  that  patterns  (l|  and  (2l  are  identical.  However,  the  two 
situations  are  different.  This  difference  shows  up  when  the  dependency 
type  is  recorded. 


Pattern  (1)  is  typically  coded  as  a  CD  (Direct  Communication). 
Pattern  ( 2 |  is  coded  as  a  non-mediated  procedural  product  dependency 
(P2;  since  products  of  individual  activity  are  exchanged),  usually  with 
a  secondary  CD  element  (i.e.,  P2,  CD). 


Pattern  or  variation  f 1 |  has,  as  the  dependency  element,  the 
transfer  of  data  and  information.  Variation  (2)  has,  as  the  dependency 
element,  the  transfer  of  completed  sections  of  the  fora. 


Dependent- v  Purpose 

Tin*  purpose  (if  Hie  first  dependency  is  the  transfer  of  data  (DA). 
The  purpose  of  the  sc-  dependency  is  the  status  of  individual 

activities  (SIA). 

NOTE:  fn  both  variations,  the  actual  completing  of  the  form  is  an 

individual  act ivit y.  The  first  variation  only  discusses  the  transfer 
of  data.  The  second  variation  only  discusses  the  transfer  of  complete 
sections  of  the  form. 


Providing  Security 


Variat ions  and  Patterns 


Two  variations  of  this  situation  have  been  observed.  The  most 
common  variation  involves  a  nested  team  which  has  been  assigned  the 
responsibility  to  provide  security  for  the  larger  team  while  the  larger 
team  is  engaged  in  another  activity.  Note  that  this  i3  a  procedural 
product  ,(P2)  pattern.  This  situation  can  best  be  represented  as  a 
fanout  pattern  between  nested  teams,  in  the  following  manner: 


I A 1 


?2 


{ B |  |C| 


-« 


m 


where  "A"  denotes  the  nested  team  providing  security,  "B”  and  "C" 
denote  two  nested  teams  of  the  larger  team  (receiving  the  security), 
and  the  double  caret  (■'<)  denotes  a  fanout  pattern. 


The  second  variation  occurs  in  two  situations.  First,  suppose  a 
squad  i  engaged  i  it  a  movement  to  contact  mission.  Each  individual  is 
providing  security  for  himself  as  well  as  other  team  members. 
Furthermore,  each  individual  is  receiving  security  from  the  other  team 
members.  This  ,i  s  the  classic  example  of  a  Type  ,  I  virtual  dependency 
and  can  be  graphically  represented  as: 

l,  2.  ....  N  U1 

VI  - * - — — 1 - 

where  vl  denotes  a  Tvpe  I  virtual  dependency  and  l  through  N  represent 
all  the  initiators  and  recipients  of  the  security. 

This  variation  a  I incurs  in  the  nested  team  example.  It  should 
be  noted  that,  pattern  (l|  represents  the  dependency  between  the 
security  nested  team  and  the  remaining  nested  teams  nr  the  larger  team. 
It  does  not  represent  the  dependency  within  the  security  nested  team. 
Within  the  security  nested  team,  each  individual, is  providing  security 
for  himself,  other  nested  team  members,  and  the  team  at  large.  Pattern 
|ll  only  shows  or  illustrates  the  latter.  Pattern  { 2 1 ,  however,  can  be 
used  to  illustrate  the  former  two  recipient*  of  t|ie  security  activity. 
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Km  <  Inti  tv,  |>.Ml<'iu  |1|  c.in  he  rewiitlen  ;i;s: 


I  ,  2,  I,  .  .  .  ,  N 


|B|  (*:l 


where  the  first  set  o(  brackets  indicates  the  security  nested  team 
(nested  team  "A”),  the  pattern  within  the  first  set  of  brackets  denotes 
the  dependency  within  the  security  nested  team,  "B"  and  "C"  denote  the 
remainiiiK  nested  teams  <>l  the  larpcr  team  (and  are  bracketed  to 
indicate  they  are  nested  teams),  and  double  caret  (<<)  denotes  a  fanout 
pattern. 


Dependency  Type 

Patterns  III  and  1 3 1  are  non-mediated  procedural  dependencies 
(P2),  whit**  pattern  (2)  is  a  Type  l  virtual  dependency. 


Dependency  Element 


The  dependency  element  for  both  patterns  is  the  provision  of 

security. 


Dependency  Purpose  • 

The  following  purposes  appear  reasonable  for  both  patterns: 
I.  Status  of  Individual/Nested  Team  Activities  (SIA). 


?.  lnform.it  ion  about  the  Enemy  or  OPFOR  (IMO). 


APPENDIX  I) 


MODEL  VALIDATION 


APPENDIX  I) 


M0DK1.  VALIDATION 

Tin'  purpose  of  this  appendix  is  to  present  a  brief  discussion  of 
the  validation  of  the  team  organization  and  performance  model  discussed 
in  Section  1  of  this  report.  At  the  conclusion  of  development  of  the 
model — after  tour  cycles  of  observations  of  teams  and  subsequent 
•  revisions  of  the  model  to  incorporate  the  team  phenomena  observed— the 
model  was  felt  to  be  substantially  complete.  The  concepts  included  in 
the  model  were  found  to  be  able  to  describe  the  nominal  and  actual 
structural  characteristics  and  the  per formance/behavioral 
characteristics  of  all  of  the  teams  and  missions  observed  to  that 
time. 

In  order  to  determine  the  extent  to  which  the  model  could  be 
judged  comprehensive,  complete,  and  conditionally  general,  however,  a 
validation  exercise  was  planned.  The  consistency  of  the  model  was 
examined  hy  observing  t earns  and  missions  that  had  been  observed 
previously  during  model  development.  Descriptions  of  the  team  missions 
observed  with  t lie  "repeat"  team  (Infantry  rifle  squads)  were  prepared, 
and  the  descri pt ions  compared  to  previously-completed  descriptions  of 
the  same  team  type  performing  both  the  same  and  different  missions. 
Using  the  "repeat"  team  descriptions,  the  following  characteristics  of 
the  model  were  identified  for  both  the  "development1*  team  mission 
descriptions  w<>re  the  "validation"  team  mission  descriptions: 

.  Number  and  titles  of  nominal  team  positions 

•Existence  of  nominal  nested  teams 

.  ,  Equipment  associated  with  nominal  nested  team  positions 

Number  of  actual  'earn  roles  and  role  titles 

Responsibj l it :es  assigned  each  actual  team  role 

.  Equipment  associated  with  each  actual  team  role 

•  Types  of  dependencies  observed  during  mission  performance 

.  Dependency  purposes  observed  (hiring  mission  performance 

Dependency  patterns  observed  during  mission  performance 

Existence  of  actual  nested  teams 

Comparison  were  made  between  two  missions  with  identical  titles 
(movement  to  contact) — one  from  development  observations,  and  the  other 
from  validation  oh.-servat ions--aiid  between  two  missions  with  different 


titles,  I  >  •  1 1  similar  ever  lit  goals:  deliberate  attack  (development), 
a  Hi  I  i  i  i  1  ••  raid  (validation).  The  same  nominal  team  type  (Infantry 
rifle  squads)  was  observed  for  all  missions.  The  development 
descriptions  were  prepared  from  observation  of  Airborne  (82nd  Division) 
squads;  t  he  validation  descriptions  were*  based  on  observation  of 
Air  Assaults  (101st  Division)  squads.  Different  squads  were  used  to 
prepare  each  of  the  four  descriptions. 

Fn  all  four  of  the  missions,  the  squads  observed  had  identical 
nominal  team  structure  (as  reported  by  the  squad  leaders);  the 
"standard”  eleven-man  squad  nominal  structure.  The  structures  observed 
each  contained  nominal  nested  teams:  the  Alpha  and  Bravo  fire  teams. 
All  four  teams  were,  however,  umlerst rcngtli  by  one  or  two  men. 
Observation  !,f  actual  team  structures  adopted  during  the  missions 
revealed  very  high  degrees  of  similarity  between  the  actual  structures 
of  rlie  four  teams,  as  well.  The  nominal  nested  team  structure  of  all 
four  teams  was  maintained  as  an  actual  structure  during  the  missions, 
although  in  one  of  the  validation  missions  (movement  to  contact)  two 
machine  gunners  were  attached  to  the  squad  being  observed  (the  squad 
was  point  squad  in  a  company  movement  to  contact).  These  individuals 
were  at ( ached 1 t o  the  squad  leader,  however,  rather  than  being 
incorporated  in  the  nested  team  structure  of  the  squad.  Only  slight 
variations  in  actual  team  role  names  wee  observed:  one  squad  leader 
designated  his  fire  teams  as  "fire"  and  "maneuver”  teams,  rather  than 
the  standard  "Alpha"  and  "Bravo"  designations. 

Especially  careful  attention  was  paid  to  characterizing  the  types, 
purposes,  and  patterns  of  dependencies  .observed  during  these  four 
missions  and  comparing  thecharacter ist ics  observed.  Summaries  of 
dependency  types,  purposes,  and  patterns  are  presented  in  Tables  l,  2, 
an  I  '5  for  all  (e.ri  t  ypes  and  missions  observed  during  model  development 

.iii  !'  v.|!  id  if  i<>n  ( not  just  the  tour  missions  considered  during  the 

validation  exercise).  As  these  tables  reflect,  the  dependency  types 
observe. |  during  the  four  missions  were  identical.  Since  this  part  of 
the  validation  effort  was  concerned  only  with  evaluating  the 
completeness  and  consistency  of  the  model,  no  frequency  tabulations  or 
other  uiimerica.l  analysis  of  dependency  types  (or  of  other  dependency 
<  h  ir.i'f  er  i  st  ic;: )  was  performed.  Similarly,  the  dependency  purposes 
.  identified  in  the  four  missions  under  cons iderst ion  were  identical,  as 
were 'the  kinds  of  dependency  patterns  observed. 

At  this  I  .'Vi- 1  ut  .mi.  i  lysis,  the  observation  and  comparison  of 
l"s-r«,it  ion  ;  of  Ho*  "r.  pe.it"  ream  missions  indicated  that  the  model  was 

os*:  ut » al  I  v  completed  within  limits  of  the  foam  types  and  missions 

*t  served.  D*i  r  i  u;>  the  valid  it  i  on  observations  and  preparation  of 
mission  <F*  <  r  i  pt  ions  fu  the  missions  observed,  all  characteristics  of 
Me*  structure,  nr  gun i y at i on ,  or  behavior  of  the  "repeat"  validation 
i ''.in*,  or  missions  could  be  accounted  for  by  concepts  of  the  model.  It 
should  be  noted  t  ft  at  some  bf  I  lie  rhagaclerist  icn  of  the  model  were  not 
required  to  descrihr  these  part icul ar  teams  and  missions  (i.e..  Type  !l 
virtual  *1*  |ieiidi*n- i es ,  physical  product  rlepeiidenc i«s ) .  This  was  deemed 
unimportant,  as  these  characteristics  were  firmly  established 


TABLE  1. 

DEPENDENCY  TYPES  OBSERVED  DURING 
MODEL  DEVELOPMENT  AND  VALIDATION 
BY  TEAM  TYPE  AND  MISSION 
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TABLE  1.  (Concluded) 
DEPENDENCY  TYPES  OBSERVED  DURING 
MODEL  DEVELOPMENT  AND  VALIDATION 
BY  TEAM  TYPE  AND  MISSION 


TABLE  2. 

DEPENDENCY  PURPOSE  CATEGORIES  OBSERVED  DURING 
MODEL  DEVELOPMENT  AND  VALIDATION 
BY  TEAM  TYPE  AND  MISSION 


For  the  meaning  of  purpose  codes,  refer  to  the  model  discussion  in  Section  1. 
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Infantry  Squad  (Embedded  sn  Platoon,  Movement  to  Contact 

Company  Operations)  _ 

(Validation)  Deliberate  Daylight  Defense 

_ _  Raid  (Airmobile) 


during  ino.l(> I  deve lopment ,  and  their  absence  in  the  particular  missions 
observed  was  predicted  from  observations  made  during  model  development. 

The  second  aspect  of  the  model  validation  exercise  was  directed 
toward  establishing  (in  a  limited  way)  the  generality  and  external 
validity  of  the  model.  To  attempt  to  verify  model  generality,  a  team 
type  which  had  not  previously  been  observed  (Field  Artillery  Fire 
Direction  Center  -  FART'Y  FDC)  was  observed.  While  the  FART’Y  FDC  is 
similar  in  concept  to  the  Infantry  mortar  FDCs  observed  during  model 
development,  the  nominal  structure  of  the  FART'Y  FDC  is  somewhat 
different,  as  are  the  details  of  procedures  used  in  the  FDC  and  the 
number  of  gun  tubes  controlled. 

Four  kinds  of  missions  wpre  observed  in  an  FART'Y  FDC:  initial1 
call  for  fire,  adjust  fire,  repeat  missions,  and  split  missions  (some 
gun  tubes  firing  at  one  target,  the  remainder  of  the  tubes  at  a 
different  target).  In  additibn  to  observing  and  describing  the 
missions,  t lie  nominal  structure  of  the  team  was  identified,  as  were  the 
actual  structures  for  each  of  the  missions  observed.  These  data  were 
•„sed  to  prepare  team  structure  and  mission  descriptic  .a,  using  the 
concepts  of  the  model. 

The  nominal  and  actual  team  structure  aspects  of  the  model  easily 
accounted  for  the  organizational  and  structural  characteristics  of  the 
FART'Y  FDC.  [dentifiying  and  naming  team  positions  and  roles,  and  the 
equipment  a;.. I  responsibilities  associated  with  each  was  very  simple, 
since  this  team  type  is  small  (seven  positions),  and  (within  the  FDC) 
there  is  no  movement .  Since  the  team  was  observed  at  mealtime  (0630), 
the  actual  team  structures  wore  always  under. strength  (people  rotated  to 
the  mess  tent  by  ones  or  twos),  even  though  the  team  was  at  ful  L 
strength.  Describing  the  various  shifts  of  roles  and  responsibilities 
was  not  a  problem  for  the  model,  however. 

The  performance  characteristics  of  the  missions  observed  were  also 
described  completely  by  model  concepts  (see  Tables  l,  2  and  3).  While 
the  types,  purposes,  and  patterns  of  dependencies  that  were  observed 
were  limited  relative  to  the  scope  of  the  model  as  a  whole  (i.e.,  only 
procedural  and  .'•ommimirat  ive-vorbal  dependencies  occtired),  no  new 
concepts  or  modifications  of  concepts  were  required  to  describe  the 
mission  performance  of  the  FART'Y  FDC  missions. 

The  objectives  of  the  model  validation  effort  were  achieved 
completely  by  the  observation  and  descript inn  of  team  missions 
■discussed  above.  Roth  the  consistency  of  description  of  different 
teams  performing  similar  or  identical  missions  at  different  times  and 
locations  ("repeat " ’  observal  ions) ,  and  the  external  validity  ("new  team 
type"  observations)  of  till*  model  were  confirmed  by  this  effort.  ,  It 
must  be  noted,  however,  that  the  overall  generality  of  the  model 
remains  unconfirmed.  The  model  lias  thus  far  been  applied  only  , to  a 
limited  variety 'of  military  teams  and  missions.  Although  the  model 
appears  ad equal e  to  account  for  a  wide  variety  of  teams  and  mission 
(tasks)  outside  the  teams  and  missions  observed  in  this  effort,  and  has 


proven  able  to  <1< ».-i I  with  hypothot  ir.il  team  behaviors  in  analyzing 
artificial  scenarios,  tin?  generality  and  external  validity  of  model 
concepts  will  he  est  ,il>  I  i  sl»e<l  only  after  wider  application  of  the  model 
and  its  concepts. 
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DEVELOPMENT  AND  VALIDATION  OP  TIIK  DESCRIPTION  METHOD 


Int  rodiict  ion 

A  previous  section  of  this  report  presented  the  final  version  of 
the  Description  Method.  That  discussion  did  not  describe  how  the 
Description  Method  was  developed  and  validated.  The  purpose  of  this 
section  is  to  describe  the  development  of  the  Description  Method  and  to 
present  the  results  of  the  validation  study  conducted  on  the  Descrip¬ 
tion  Method. 


background  tnlormat  ion 

Very  early  in  the  project,  a  set  of  objectives  wore  developed  for 
the  Description  Method.  It  was  this  set  of  objectives  that  guided  the 
development  of  the  method.  These  objectives  were: 

1.  The  Description  Method  had  to  flow  logically  from  the  model 
of  team  performance  and  behavior.  The  model  of  team 
performance  and  behavior  had. to  identify  those  factors  or 
dimensions  which  constituted  team  performance  and  behavior. 
Thus,  one  of  the  objectives  of  the  Description  Method  was 
to  develop  procedures  for  describing  those  factors  and 
dimensions  of  team  performance  and  behavior  that  the  model 
identified  as  being  critical  and  important. 

2.  The  application  of  the  Description  Method  on  a  specific 
te.iin  type  and  a  specific  team  mission  had  to  generate 
usable  team  and  team  mission  descriptions.  Usable  was 
defined  to  mean,  useful  in  identifying  team  training 
requirements  and  measures  of  team  performance. 

3.  The  Description  Method  had  to  not  only  contain  recording 
forms  which  const i f ut ed.  the  team  and  team  mission  descrip¬ 
tions,  but  it  also  had  to  contain  a  set  of  procedurs  for 
gewr at  ing  »!•<•  data  or  information  which  was  to  be  entered 
on  flu*  forms  (the  descriptions). 

A,.  The  Description  Method  had  to  be  applicable  to  the  wide  , 
variety  of  teams  encountered  in  the  Army.  In  addition,  it 
had  to  he  applicable  to  the  wide  variety  of  missions 
pel  formed  by  Aimy  teams. 


•».  Ilf  Description  Met  hod  li.nl  to  be  .is  prescriptive  as 

possible,  since  it  was  ant  ic  i  pal  is!  that  tin*  met  hod  would 
eventually  be  applied  hy  military  personnel  (e.g.,  training 
deve  I  opers  ) . 

The,  attainment  of  these  objectives  was  not  all  scheduled  for  the 
first  year  of  tin*  project.  For  example,  the  attainment  of  Objective  2 
could  »»<*t  be  assessed  in  the  first  year  of  the  project,  since  the 
development  of  tin*  training  requirements  identification  procedure  and 
the  development  of  tin*  procedure  to  identify  measures  of  team 
performance  were  not  scheduled  for  completion  until  the  second  and 
thrid  years  of  the  project.  Thus,  it  is  impossible  during  the  first 
year  to  determine  if  the  Description  Method  generated  descriptions 
which  were  useful  in  identifying  team  training  requirements  and 
measures  of  team  performance.  Similarly,  the  attainment  of  Objective  5 
could  not  be  assessed  at  the  end  of  the  first  year.  During  the  first 
year  of  the  project,  military  personnel  were  not  scheduled  to  apply  to 
the  Description  Method.  Only  the  project  staff  would  have  an 
opportunity  ,to  apply  the  method  during  the  first  year. 

The  attainment  of  Objectives  l  and  4  could  only  be  moderately 
assessed  at  the  end  of  the  first  year.  Notice  that  both  of  these 
objectives  concern  the  validity  of  the  descriptions  generated  by  the 
Description  Method.  The  Description  Method  can  only  be  as  valid  as  the 
■mule l  of  team  performance  and  behavior.  If  the  model  is  applicable  to 
the  wide  variety  of  Army  learns  and  missions,  then  the  Description 
Method  void d  also  he  applicable.  , If  the  model  correctly  identifies  the 
most  important  and  critical  factors  and  dimensions  of  teams  and  team 
behavior,  then  the  Description  Method  would  also.  This  tautology 
exists  because  of  the  way  the  Description  Kitliod  was  developed.  ■  The 
Description  Method  was  derived  directly  from  the  model.  It  was  not 
empiriiilly  derived.  Thus  to  a  large  extent,  the  validity  of  the 
Description  Method  is  extremely  dependent  upon  the  validity  of  the 
model.  in  addition,  the  Description  Method  was  only  applied  to  one 
team  type  during  the  validation  exercise.' 

I!y  the  process  of  elimination.  Objective  3  became  the  major  focus  , 
of  the  first  year's  effort  with  respect  to  the  Description  Method, 
basically,  the  first  year  concentrated  on: 

1.  Developing  recording  forms  which  would  constitute  the 
descriptions  of  teams  and  team  missions. 

? .  Developing  procedures  to  generate  the  data  or  information 
whit'll  would  he  entered  in  the  recording  forms. 
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Overview  of  Wove lopmont  Process 


The  Description  Method  was  developed  in  three  relatively  separate 
and  distinct  stages.  Tfiese  were: 

I.  The  Primitive  Description  Method.  During  the  development 
of  the  model  of  team' performance  and  behavior,  a  .very 
primitive  Description  Method  was  developed.  The  purpose  of 
the  primitive  method  was  solely  to  facilitate  the 
development  of  tire  model.  Although  the  primitive  riethod 
was  l  lie  forerunner  of  the  final  Description  method,  it  was 
not  reaily  designed  to  satisfy  the  stated  objectives. 

.  Pi e I i mi  nary  Description  Method .  After  the  model  of  team 
performance  and  behavior  was  validated,  a  preliminary 
Description  Method  was  developed.  This  preliminary  method 
was  derived  directly  ftom  the  model  and  was  systematically 
designed  to  satisfy  the  stated  objectives  of  the  Descrip¬ 
tion  Method.  It  was  this  preliminary  method  that  was 
validated. 

).  Final  Version  of  the  Description  Method.  After  the 
preliminary  method  was  validated,  it  was  revised  and 
modified  to  become  the  final  version.* 


The  developmental  activities  that  occurred  in  each  of  these  phases  or 
stages  ar<*  discussed  in  detail  below. 


The  Primitive  Description  Method 

Originally  the  Description  Method  was  not  scheduled  for  develop¬ 
ment  until  after  the  theoretical  model  of  team  performance  and  behavior 
was  built  and  validated.  However,  during  the  model  development  activ¬ 
ity,  it  became  clear  that  some  sort  of  recording  forms  would  be  needed. 
The  mini  el  was  developed,  by  observing  actual  teams  performing  actual 
mission.-..  ,ln  order  to  refine  the  concepts  in  the  model  and  to  identify 
new  concepts,  it  was  necessary  to  record  the  information  obtained 
during  these  observations.  To  facilitate  the  development  ol  the  model, 
a  set  of  extremely  primitive  recording  forms  wore  developed.  These 
primitive  forms  were  designed  with  the  following  characteristics  in 
mind: 


^Filial  version  refers  to  the  final  version  developed  at  the  end  of 
the  first  year  ol  the  o||nrt.  In  a- sense,  this  version  should  not  he 
considered  the  absolute  final  version,  since  it  is  expected  that  the 
second  and  third  years  ol  the  project  will  require  modification  and 
additions  to  the  method. 


1.  -  lin*  Iimiiis  would  only  be  used  l»y  tin*  j  c*c' t  staff.  Thus, 

they  did  not  nood  to  In*  soph i st  ic.it t*d  or  procedural . 

2.  Tli**  •:**!  of  forms  did  not  have  to  he  complete  or  comprehen¬ 
sive.  ft  was  n**v**r  inf**n<lt*tl  th.it  .1  set  of  forms  be 
completed  for  each  observation  during  the  model  development 
activity.  The  intent  was  not  to  describe  each  observation 
in  detail;  the  intent  was  to  describe  only  those  segments 
or  parts  of  the  observation  which  might  have  impacted  upon 
tin*  refinement  of  an  existing  team  and  team  behavior 
concept  or  in  the  ident i f icat ion  of  a  "new"  concept;  i.e., 
the  lonns  were  only  viewed  as  a  mechanism  to  describe 
som.'t  It i iij*  nor  previously  observed  which  would  likely  lend 
to  concept  refinements. 

1.  Th<*  forms  were  geared  to  the  observation  format  of 
collecting  data.  No  attempt  was  made  to  worry  about 
alternative  ways  of  generating  the  data  to  be  recorded; 
i.e.,  primitive  method  was • not  concerned  about  how  the  data 
spec  i  I  ied  on  the  forms  should  he  generated.’ 

The  Primitive  Description  Method  evolved  as  the  model  itself 
evolved,  but  th**  relationship  was  an  inverse  relationship.  As  the 
concepts  of  the  merle  1  become  clearer  and  clearer,  the  need  for  a  more 
systematic  primitive  Description  Method  decreased;  i.e.,  as  the  mcdel 
builders  became  more  familiar  with  each  concept,  it  was  easier  to 
identify  and  thus,  easier  to  record  incidents  which  would  impact  upon 
the  model.  Thus,  the  primitive  forms  were  used  less  and  less  until 
finally  tin*  primitive  forms  were  entirely  replaced  by  briefly  written 
narratives.  The  narratives  concentrated  on  describing  observed  team 
mission  activities  which  bad  the  potential  to  refine  the  concepts 
contained  in  flu*  m***l<*,l .  This  was  not  considered  harmful  or  detri- 
mont.il.  It  should  •>*•  remembered  that  th«  primary  purpose  of  the 
primil  ive  lie  si  r  i  pi  ioo  Method  was  to  facilitate  the  model  development 
activity  an<l  not  to  advance  the  state  of  the  Description  Method, 

The  Primitive  Description  Method  contained  the  following  recording 
forms: 

!.  Actual  and  nominal  team  structure  recording  forms.  These 
forms,  were  designed  to  record  the  actual  team  structure,  as 
w<*  II  as  •  describe  how  the  actual  team  structure  was 
different  from  f  lie  nominal  team  structure.  This  form  was 
iut retpionf ly  used  during  the  mode  1  development  process, 
simply  because  the  concepts  associated  with  the  actual  team 
st ruct ure  and  the  nominal  team  structure  were  quickly 
confirmed  (and/or  refined). 

2.  An  equipment  list  recording  form.  This  form  was  also 
infrequently  employed  (luring  the  model  observation  phase  of 
Hie  project ,  simply  because  the  concepts  of  the  model  in 
this  area  were  relatively  st  might  forward. 


1 . 


A  si  Mint  inn, *it  map  recording  form.  Tins  recording  form  had 
a  high  frequency  of  us<*  during  the  initial  stages  of  model 
d*-v*,  |  opincnt .  It  was  not  particularly  related  to  any  given 

concept  in  the  model,  hut  if  did  provide  the  project  staff 
a  useful  vehicle  for  conveying  the  overall  intent  of  the 
observed  mission.  These  situational  maps  were  quite 
f rbquent  Iv  used  during  staff  meetings,  when  concept*  were 
being  discussed  and  refined. 

4.  A  primitive  team  mission  activities  recording  form.  This 
lorm  was  designed  to  capture  either  the  whole  mission  or 
certain  segments  of  the  mission  activities.  The  form 
consisted  of  ten  columns  (one  column  was  devoted  to  each 
performer).  Relow  the  column  headings  were  1/4  inch  by  1/4 
inch  blocks  or  boxes.  An  "XM  was  placed  in  the  box  of  the 
performer  who  initiated  the  dependencies  being  recorded, 
bines  were  drawn  from  the  box  with' the  ”X"  to  the  recip¬ 
ients  of  the  dependency.  The  vertical  dimensions  of  the 
form  indicated  the  relative  time  between  dependencies  or 
individual  act  ions.  The  form  also  contained  a  comments 
column  for  each  row  of  boxes  (each  row  described  a 
dependency).  The  comment s  column  was  reserved  for 
recording  the  dependency  element  of  the  dependency  recorded 
in  the  row. 


This  form  was  frequently  used  in  the  early  observation  to 
record  most,  if  not  all,  the  observed  dependencies.  As  the 
dependency  concepts  were  further  reviewed,  the  form  was 
used  less  and  less. 


This  form  turned  out  to  he  very  useful  to' the  model  devel¬ 
opment  activities.  In  fact,  it  was  this  form  which  led  to 
I  lie  •  oncepf  of  dependency  patterns.  It  was  noticed  very 
early  during  the  observation  phase  that  the  boxes  tended 
to  form  patterns  and  the  some  patterns  tended  to  be 
repeatedly  observed.  As  the  observation  phase  progressed, 
the  project  staff  tended  to  record  patterns  rather  than 
using  the  forms. 


Altnongh  the  primitive  Description  Method  was  used  spa 
(e.,;.f  only  used  when  it  was  necessary  to  describe  a  set  of 
activities  which  had  the  potential  to  affect  the  model),  it 
application  resulted  in  some  useful  lessons  learned.  The  1 
learned  i  an  lie  gimiped  into  I  wo  categories.  bessons  wore  l 
the  recording  forms,  and  lessons  were  learned  about  the  obscj 
technique  of  collect ing  dat a;  i.e.,  techniques  for  geuerati 
to  he  entered  in  •  lie  forms,  first,  the  lessons  learned  abut) 
recording  forms: 


l.  The  recording  forms  comprising  the  primitive  Des 
Method  appeared  to  be  applicable  to  a  wide  vari 
and  team  mi ss ions .  At  least  it  appeared  applic 
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those  I  imiii  .nul  team  missions  which  were  observed  during  the 
model  building  activity. 

2.  The  primitive  mission  activities  recording  form,  although 
easy  to  complete,  was  difficult  to  interpret  and  read; 
i.e.,  individuals  who  did  not  participate  in  the  observa¬ 
tion  of  the  mission  found  it  difficult  to  review  the  form 
and  capture . the  flavor  of  the  mission.  The  project  staff 
felt  it  would  have  been  difficult  to  use  the  completed  form 
to  identify  team  training  requirements  and  measures  of  team 
performance.  The  form  required  recording  too  little 
information  about  the  mission,  mission  activities,  and 
individual  activities.  .  The  form  would  need  to  be  revised 
during  the  devel opment  of  the  Description  Method. 

1.  The  forms  were  reasonable  devices  for  recording  observed 
activities,  but  they  could  not  he  used  during  the 
observation  in  a  field  environment.  They  were  paper  and 
penc i )  devices,  thus  could  not  l>e  manipulated  in  adverse 
environments  (extreme  temperatures,  windy  conditions, 
precipitation,  etc.). 

4.  To  complete  the  forms,  the  preparer  had  to  be  familiar  with 
the  concepts  contained  in  the  model  of  team  performance  and 
behavior.  Hie  forms  were  not  stand-alone  recording 
devices.  It  should  be  pointed  out  that  there  were  no 
instructions  developed  for  complet i ng  the  forms  of  the 
primitive  Description  Method.  It  was  quickly  realized  that 
i list  met  ions  would  bo  needed  fr  *  the  final  version, 
furthermore,  it  was  realized  that  the  instructions  could 
never  really.be  made  very  prescriptive,  part icularly  for 
completing  the  team  mission  activities  recording  form. 

Dependencies  occur  differently  within  each  mission.  Thus, 
the  procedures  for  completing  the  form  could  not  be  made 
very  prescriptive.  It  was  at  this  point  in  the  project 
that  the  staff  started  to  search  for  some  guidance  which 
could  he  given  to  the  end-users  of  the  method.  It  was 
realized  that  specific  procedures  or  instructions  could  be 
developed  for  recording  any  given  dependency  or  team 
.activity,  but  such  specific  instructions  could  not  be  given 
for  completing  the  entire  form,  since  the  missions  to  be 
described  would  vary  considerably. 

The  observation  format  resulted  in  the  following  lessons  learned: 

I.  Since  i  lie  forms  mol'd  not  ho  used  in  the  field  environment 
while  actually  conducting  the  observation,  some  other 
ohser vat  ion  t *u  »»rd i ng  method  or  technique  was  required. 

The  alternate  technique  could  he  used  to  record  the 
observations,  and  from  the  observation  data,  the  recording 
fortus  of  the  primitive  Description  Method  could  then  be 
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romp  I  rtf'll.  The  following  two  al  fernat  i  ve  observation 
recording  methods  or  techniques  were  tried  during  the  very 
early  stages: 

a.  Videotape, 
h.  Audiotape. 

Videotape  was  cumbersome  for  some  missions,  particularly 
those  missions  where  the  team  was  required  to  move  rapidly 
through  the  woods  or  other  difficult  terrain.  In  addition, 
l  lie  videotape  equipment'  required  at  least  two  operators. 
Furthermore,  we  experienced  many  equipment  malfunctions  due 
to  the  environment  (rough  terrain,  dust,  precipitation, 
extreme  temperatures,  etc.). 

Audiotape  appeared  to  work  the  best.  Hand  held  tape 
recorders  could  easily  be  obtained  an«l  were  extremely 
transportable  anti  reliable.  They  could  also  be  easily 
protected  from  adverse  environmental  conditions. 

Some  l  train  mi  ss  ions,  could  not  be  easily  observed  by  one 
observer.  During  the  model  phase,  there  were  at  least  two 
observers  per  mission.  It  was  determined  that  at  least  two 
observers  won  I  <1  be  required  under  the  following 
cowl  i  t  i ons : 

a.  When  the  team  was  larger  (e.g.,  greater  than  ten 
team  members). 

b.  When  l  lie  t  eam  was  organized  into  nested  teams,  and 
the  nested  teams  performed  concurrently.  This  was 
particularly  true  when  the  nested  teams  performed  in 
pliysc  i  .1 1  I  y  different  locations. 

c.  Wl»»*n  the  set  of  activities  performed  by  the  nested 
team  or  team(s)  were  not  repetitive;  i.e.,  when  the. 
various  nested  teams  wete  not  all  doing  the  same 
thing  or  performing  the  same  function  (regardless  of 
whether  the  nested  teams  were  located  physcially 
close  to  each  other  or  not).. 

The  observation  format  would  only  work  if  the  observers 
knew  what:  to  look  For;  i.e.,  could  recognize  a  team 
activity  nr  dependency.  The  primitive  Description  Method 
contained  no  guidelines  concerning  what  to  look  for.  The 
final  Description  Method  bad  to  rectify  this  problem.  It 
had  to  provide  some  guidance  concerning  how  to  identify 
team  behaviors,  activities,  and  dependencies. 

The  ohservat  i on  format,  required  considerable  pre-planning. 
Arrangements  hail  to  be  made  to  observe  specific  missions. 

It  was  realized  that  conduct  tug  observations  takes  a  long 
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tiiiir.  Snma»  <>I  llu‘  ol»;;i'rvi**l  missions  involved  a  lapsed  time 
of  six  hours  or  more.  Furthermore,  there  was  some 
downline,  time  spent  waiting  for  the  team  to  get  started. 

These  lessons  learned  contributed  to  the  final  design  of  the 
Description  Method. 


Preliminary  Description  Method 

After  the  model  of. team  performance  and  behavior  was  judged 
relatively  stable  (and  verified),  a  second  version  of  the  Description 
Method  was  developed.  This  preliminary  Description  Method  was  derived 
directly  from  the  model  and  the  primitive  Description  Method.  The 
preliminary  Description  Method  was  primarily  designed  to  serve  as  a 
method  which  could  he  verified  or  validated.  It  was  labeled  a 
preliminary  method  because  it  was  expected  that  the  method  would  be 
considerably  revised  after  the  validation  study. 

Before  describing  the  validation  study  and  results,  it  is  perhaps 
reasonable  In  describe  the  factors  which  influenced  the  development  of 
the  preliminary  method: 

1.  The  preliminary  Description  Method  was  designed  to  be  used 
only  by  the  project  staff.  It  was  not  designed  to  be  an 
exportable  method.  Tims,  the  preliminary  method  contained 
only  the  necessary  recording  forms  and  minimum  directions 
for  completing  those  forms.  The  instructions  were  written 
For  the  project  staff,  who  were  familiar  with  the  model, 
and  not  for  military  personnel  or.  other  researchers. 

2.  The  preliminary  Description  Method  concentrated  on  identi¬ 
fying  the  data  items  that  had  to  be  included  on  the  record¬ 
ing  forms.  No. attention  was  given  as  to  how  the  data 
entered  on  the  forms  should  be  generated.  For  example,  the 
preliminary  Description  Method  did  not  provide  guidance  on 
how  to  identify  team  behaviors,  activities,  or  depend¬ 
encies;  only  how  to  record  them  once  they  were  identified. 
This, was  considered  acceptable  for  two  reasons: 

a.  The  validation  study  was  primarily  designed  to 

determine  how  the  data  entered  on  the  forms  should 
he  generated.  The  method  used  to  generated  the  data 
would  influence  the  instructions  given  to  the 
end-users. 

b ;  Only  the?  project  staff  would  be  using  the  method, 
and  l  hey  had  considerable  experience  in  identifying 
dependencies  by  developing  the  model. 


3.  The  preliminary  Description  Method  only  contained 

.procedures  for  describing  a  given  team  type  and  a  given 
mission.  That  is,  the  method  did  not  contain  procedures 
for  selecting  the  team  type'  to  be  described  or  for 
selecting  those  team  missions  which  should  be  described. 

The  sampling  problem  was  totally  avoided  by  the  preliminary 
method  for  several  reasons: 

a.  The  interest  was  in  having  recording  forms  Which 
would  work  (i.e.,  the  sampling  problem  was 
considered  a  secondary  issue  which  would  not 
influence  the  design  of  the  recording  forms). 

b.  Any  sampling  procedure  which  would  have  been 
designed  had  to  consider  how  the  completed  recording 
forms  would.be  used  to  develop  team  training  and 
identify  measures  of  team  performance.  At  this 
point  in  the  project,  the  project  staff  only  had  a 
few  ideas  what  the  training  .requirements  identifica¬ 
tion  process  would  look  like.  Thus,  it  was 
considered  wise  to  postpone  developing  a  sampling 
procedure  for  the  preliminary  Description  Method. 

Given  these  intentions,  the  preliminary  Description  Method  was 
developed  in  the  following  manner: 

1.  The  model  that  existed  at  the  time  was  divided  into  its 
components  (e.g..  General  Team  Type  Information,  Nominal 
Team  Structure  Information,  Actual  Team  Structure 
Information,  and  Specific  Mission  Informat  ion) . 

2.  The  project  staff  met  in  a  brainstorming  session  and  listed 
.all  the  flat  a  items  that-  needed  to  be  collected  for  each 
model  component . 

3.  The  identified  data  items  were  organized  in  an  apparent 
systematic:  order,  as  well  as  rephrased.  The  reorganized 
data  items  were  then  reviewed  by  the  project  staff. 

4.  After  some  modification  of  the  data  items,  the  recording 
forms  were  developed.  The  recording-  forms  were  reviewed  by 
each  senior  'project  staff  member.  They  were  reviewed  for 
accuracy  and  completeness. 

3.  Tor  <‘.nh  form,  a  set  of  instructions  was  developed.  Again, 
the  directions,  did  not  include  how  the  data  was  to  be 
generated,  only  recorded.  In  fact,  the  staff  attempted  to 
guarantee  that  the  forms  were  agnostic  toward  any  given 
method  of  data  collection,  since  the  validation  exercise 
required  collecting  data  from  three  different  sources. 


The  preliminary  Description  Method  contained  the  following  recording 
forms: 

1.  A  Team  Mission  Listing. 

2.,  Nominal  Team  Structure  Recording  Form. 

3.  Nominal  Team  Structure  Organizational  Chart  Recording  Form. 

4.  Mission  Description  Recording  Form. 

5.  A  Mission  Typographical  Map  Recording  Form. 

6.  An  Actual  Team  Structure  Recording  Form. 

7.  An  Actual  Team  Structure  Organizational  Chart  Recording 
Form. 

8.  An  Actual  Team  Structure  Deviation  Report. 

9.  Team  Member  Mission  Functions  Recording  Form. 

10.  A  Mission  Activities  Description  Recording  Form. 

In  addition,  the  preliminary  Description  Method  made  provisions  for 
generating  a  narrative  of  each  mission.  A  description  of  each  of  the 
forms  and  the  format  for  these  narratives  are  provided  in  an  interim 
report,  and  as  such,  will  not  be  described  here. 

The  preliminary  method  was  then  reviewed  by  the  Technical  Monitor. 
Both  the  forms  and  the  insttuctions  for  completing  the  forms  were 
reviewed,  and  the  method  was  approved  (i.e.,  approval  was  given  to 
proceed  with  the  validation  exercise). 

Validation  Plan 


The  validation  exercise  had  three  primary  objectives.  These 

were: 

1.  To  determine  if  two  or  more  independent  preparers  could 
generate  similar  completed  recording  forms  (team  type  and 
team  mission  descriptions)  for  the  same  team  type  and  the 
same  team  mission,  using  the  same  sources,  separately. 

2.  To  determine  the  similarities  and  differences  of 
descriptions  generated  from  three  sources  (military 
documentation,  SME  interviews,  and  observations). 

3.  to  determine  the  problems  associated  with  generating 
information  from  the  three  primary  sources. 
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Basically,  Che  validation  plan  was  simple  and  straightforward.  A 
team  type  would  be  selected  along  with  specific  missions  to  be 
described.  The  recording  form  contained  in  the  preliminary  Description 
Method  would  be  completed  by  at  least  two  senior  project  staff  members 
(working  independent Jy)  using  the  three  identified  sources,  separately. 
That  is,  first  descriptions  would  be  generated  using  documentation. 

The  descriptions  generated  by  the  two  independent  pireparers  would  then 
be  compared,  and  the  differences  and  similarities  highlighted.  The  two 
independent  sets  of  descriptions  would  then  be  consolidated  into  one 
set  of  descriptions  which  would  represent  the  team  and  team  mission 
descriptions  generated  from  documentation.  Next  the  same  two  independ¬ 
ent  preparers  would  generate  descriptions  for  the  same  team  type  and 
same  missions  using  the  SME  interview  technique.  The  two  sets  of 
descriptions  generated  by  the  preparers  would  then  be  compared,  and  the 
differences  and  similarities  highlighted.  One  set  of  descriptions 
representing  what  can  be  accomplished  from  SME  interviews  would  then  be 
generated.  This  set  would  be  compared  to  the  set  generated  from 
documentation  alone.  Hie  process  was  then  basically  repeated  for  the 
descriptions  gnerated  from  obsrvation.  This  approach  accommodated  the 
reliability  issue;  it  would  provide  information  concerning  whether  two 
independent  preparers  could  generate  similar  descriptions  using  each  of 
the  sources.  It  also  accommodated  the  other  objectives  since  it  would 
be  possible  to  determine  if  the  descriptions  gnerated  from  the  three 
sources  were,  in  fact,  different.  Furthermore,  the.  approach  would 
highlight  the  problems  associated  with  using  each  source. 

It  was  determined  that  the  target  team  type  for  the  validation 
effort  would  be  Combat  Engineers,  mechanized  (both  squads  and 
platoons).  Combat  Engineers  were  selected  for  several  reasons.  First, 
they  could  be  made  available  for  SME  interviews  and  observations. 
Second,. on  the  surface  Combat  Engineers  appeared  to  perform  a  wide 
variety  of  team  missions  (i.e.,  the  team  missions  did  not  appear  to  be 
repetitive  or  similar).  For  example,  installing  tactical  minefield 
appeared  to  involve  different  team  behaviors  than  preparing  a  target 
folder.  This  would  permit  some  assessment  of  how  well  the  preliminary 
Description  Method  could  be  applied  to  a  wide  variety  of  team 
missions. 

Since  the  preliminary  Description  Method  did  not  contain  proce¬ 
dures  for  sampling  the  missions  to  be  described,  the  Technical.  Monitor 
(with  the  assistance  of  FORSCOM  personnel,  SMEs,  and  the  project  staff) 
arbitrarily  selected  the  missions  to  be  described.  The  criteria  used 
in  this  proceess  were: 

1.  Team  mission  variability;  i.e.,  the  selected  mission  had  to 
be  different  with  respect  to  suspected  team  behavior  in 
order  to  determine  if  the  forms  were  appropriate  for  a  wide 
variety  of  the  missions. 

2.  Expectancy  of  observation;  i.e.,  the  selected  missions  had 
to  be  observable;  one  which  might  be  practiced  in  a  normal 
field  exercise. 


3.  Mission  length;  i.e.,  there  was  interest  in  selecting 
mission  which  would  take  no  longer  than  eight  hours  to 
compelte  or  observe. 

4.  Combat  influence;  i.e.,  the  selected  missions  had  to  be 
ones  which  would  normally  be  performed  in  combat,  since  it 
was  felt  that  the  description  techniques  would  eventually 
be  used  to  describe  such  missions. 

Discussions  with  SMEs  revealed  two  Major  Mission  Areas  which  were  good 
candidates:  Mobility  and  Countermobility.  This  was  sufficient  for  our 
purposes,  since  no  attempt  was  being  made  to  select  a  representative 
sample  of  mission  or  mission  areas;  i.e.,  the  descriptions  generated 
from  the  application  of  the  preliminary  Description  Method  were  not 
going  to  be  used  to  identify  team  training  requirements.  Thus,  a 
rigorous  or  systematic  sample  was  not  required. 

The  following  missions  within  the  Mobility  Mission  Area  were 
selected,  according  to  the  established  criteria: 

1.  Clearing  a  Log  Crib  Obstacle. 

2.  Breaching  a  Minefield. 

The  following  missions  from  Countermobility  were  also  selected, 
according  to  the  established  criteria: 

3.  Constructing  a  Log  Crib. 

4.  Preparing  a  Target  Folder. 

5.  Installing  a  Tactical  Minefield. 

It  was  initially  planned  that  the  same  five  missions  would  be  used 
throughout  the  validation  study;  i.e.,  the  same  five  missions  would  be 
described  using  dopumentat ion,  SHE  interviews,  and  observation.  How¬ 
ever,  this  was  not  the  case.  The  list  of  missions  was  somewhat  altered 
during  the  validation  exercise.  Alterations  were  needed  in  the  list 
because  it  was  difficult  early  in  the  validation  effort  to  precisely 
determine  which  missions  would  actually  be  observed.  Our  approach  was 
to  mitigate  the  demand  on  FOR$COM  field  units  by  observing  missions 
which  would  be  practical  in  a  normal  field  exercise*  The  field  exer¬ 
cise  was  in  the  process  of  being  prepared  when  the  initial  list  of 
missions  was  selected.  As  time  progressed,  the  field  exercise  changed, 
and  the  initial  list  had  to  be  altered  immediately  proceeding  the  SMB 
interview  phase  of  the  validation  exercise.  The  missions  described  at 
each  phase  of  the  validation  effort  are  reported  in  Table  l. 
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Table  1 


Missions  Described  by  Source 


Mission 

Source  I 

Documentation 

Interview 

Observation 

Clearing  Log  Crib 

X 

X 

Breaching  Minefield 

X 

Constructing  Log  Crib 

X 

X 

X 

Preparing  a  Target 

, 

Folder 

X 

X 

X 

Installing  at  Tactical 

Minefield 

X 

X 

X 

Constructing  a  Barbed 

1 

Wire  Entangement 

X 

Reconnaissance  of 

Bridge 

X 

X 

Bridge  Demolition 

X 

Installing  a  Point 

Minefield 

X 

t 

It  should  be  noted  that  only  three  missions  were  common  to  all 
three  sources  (Constructing  a  Log  Crib,  Preparing  a  Target  Folder, 
Installing  a  Tactical  Minefield).  It  was  discovered  during  the  obser¬ 
vation  phases  that  Preparing  a  Target  Folder  was  more  of  an  Individual 
activity  than  a  team  activity.  Thus,  only  two  mission  descriptions 
could  bo  compared  across  all  three  sources.  It  should  also  be  noted 
that  four  missions  were  described  by  only  one  of  the  sources,  meaning 
that  comparisons  across  sources  would  not  be  possible  on  these 
missions.  However,  two  missions  were  described  by  at  least  two 
sources,  permitting  some  degree  comparison  between  documentation  and 
SME  interviews  for  one  mission  (Clearing  a  Log  Crib),  and  a  comparison 
between  SME  interviews  and  observation  for  the  other  mission 
(Reconnaissance  of  a  Bridge).  In  total,  very  few  comparisons  could 
actually  be  made. 

The  same  two  Individuals  were  involved  in  all  three  phases  of  the 
validation  effort.  During  the  observation  phase,  a  third  individual 
was  added.  A  third  observer  was  added  in  order  to  determine  if  a  naive 
observer  could  use  the  preliminary  Description  Method.  The  observer 
was  naive  with  respect  to  the  missions,  but  not  naive  with  respect  to 
the  preliminary  Description  Method.  It  wns  thought  that  by  adding  this 
third  observer,  it  would  be  possible  to  assess  the  effect  of  partici¬ 
pating  in  the  documentation  review  and  SME  interview  process  (i.e.,  to 
isolate  the  kind  of  information  that  would  be  added  or  deleted  by  an 
observer  who  did  not  know  anything  about  the  missions  bring 
described). 
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Introduction  to  Validation  Results 

For  clarity,  the  results  of  the  validation  effort  are  presented  in 
three  separate  sections.  It  should  be  recalled  that  the  validation 
effort  had  three  primary  objectives  (reliability  between  preparers,  the 
similarity  or  differences  between  the  descriptions  generated  by  the 
three  sources,  and  the  problems  encountered  in  using  each  source). 

There  is  one  section  devoted  to  each  of  these  objectives. 


Consistency  Between  Preparers 

No  statistical  tests  or  procedures  were  used  to  determine  the 
degree  of  consistency  (or  agreement)  between  the  independent  preparers. 
The  preparers  reviewed  each  others  descriptions  and  noted  areas  of 
agreement  and  disagreement.  Areas  of  consistency  (and/or 
inconsistency)  were  further  clarified  when  the  two  dependent  preparers 
generated  the  consolidated  descriptions.  The  consolidated  descriptions 
were  generated  by  collapsing  (of  expanding)  the  descriptions  generated 
by  the  preparers  into  a  single  description  for  each  team  type  and  each 
each  mission  by  source. 

To  report  the  results  of  this  part  of  the  validation  effort,  a 
series  of  tables  are  presented.  The  tables  highlight  areas  of 
consistency  and  inconsistency  between  the  preparers  for  each  source. 
There  is  one  table  for  each  of  the  three  sources  that  were  used.  Areas 
of  consistency  or  inconsistency  are  reported  as  data  items  (e.g., 
existence  of  dependencies,  dependency  elements,  nominal  team  position 
titles,  size  of  nominal  team,  etc*).  It  should  be  noted  that  the  data 
items  fall  into  three  major  categories  (data  items  describing  the 
nominal  team,  data  Items  describing  the  actual  team,  and  data  items 
describing  the  mission  and  team  behaviors).  The  labels  of  the  data 
items  typically  indicate  its  membership  in  one  of  the  three  categories. 
It  should  also  be  mentioned  that  the  tables  present  areas  of 
consistency  and  inconsistency  collapsed  across  the  various  missions  and 
team  types  described  during  the  validation  exercise;  i.e.,  the  tables 
are  agnostic  toward  each,  mission  and  team  type.  . 

Table  2  presents  the  areas  of  consistency  and  inconsistency 
between  the  two  independent  preparers  when  military  documentation  was 
used  as  the  primary  source.  Table  3  presents  the  same  information  when 
SMC  Interviews  were  used  as  the  primary  source  for  preparing  the 
descriptions,  and  Table  4  presents  the  areas  of  agreement  and 
disagreement  when  direct  observation  was  used  as  the  primary  source. 

A  brief  discussion  of  the  results  reported  in  Tables  2,  3,  and  4 
is  appropriate.  It  should  be  noted  that  the  degree  of  consistency 
between  independent  preparers  varied  by  source.  In  general,  the  least 
attractive  degree  of  consistency  occurred  when  SME  Interviews  were  used 
as  the  primary  source.  The  highest  degree  of  consistency  occurred  when 
direct  observation  was  employed.  These  results  raise  a  critical  issue. 
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Consistency  Between  TVn  Independent  Observers  Who  Participated  in  Other  Ruses  of  Validation  Efforts 
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Do  tlie  results  indicate  that  preparers  could  not  teliably  apply  the 
method ,  or  do  the  results  indicate  that  the  sources  vary  in  their 
ability  to  provide  the  necessary  information;  i.e.,  was  it  the  sources 
which  caused  the  preparers  to  generate  descriptions  which  appeared 
similar  or  dissimilar?  To  answer  this  question,  the  following  must  be 
recalled: 

1.  The  two  preparers  interviewed  different  SMEs.^  The 
differences  in  the  descriptions  appeared  to  be  due  to  the 
different  opinions  (and/or  judgments)  the  SMEs  had  about 
the  team  type  and  the  missions  and  not  due  to  how  the 
preparers  applied  the  method. V 

2.  The  two  preparers  used  approximately  the  same  military 
documentation.  However,  the  documentation  was  frequently 
incomplete  causing  the  preparers  to  make  many  inferences 
and  assumptions  (e.g.,  as  to  who  initiated  a  dependency, 
who  received  the  dependency,  etc.).  Different  assumptions 
caused  the  preparers  to  generate  different  descriptions. 

1.  During  the  observation  phase,  the  two  preparer?  observed 
the  same  actual  team  performing  the  same  missions  at  the 
same  time  (i.e.,  the  missions  were  not  repeated  for  each 
observer).  Because  both  preparers  were  observing  the  same 
events  their  descriptions  looked  remarkably  similar. 

Thus,  it  would  appear  that  given  a  fixed  set  of  inputs  (like  in  direct 
observation),  two  independent  preparers  can  reliably  apply  the  method. 
In  the  SME  interview  and  the  military  documentation  cases,  the  reasons 
for  the  inconsistencies  appear  to  be  the  inconsistencies  in  the  sources 
and  not  in  the  way  the  preparers  applied  the  method.  If  SMEs  give 
different  inputs,  then  it  makes  sense  that  the  resulting  descriptions 
would  be  different,  regardless  of  the  reliability  of  the  preparers  to 
apply  the  method.  This  same  rationale  applies  to  using  documentation. 
If  preparer*  make  different  assumptions  while  reading  the  documents** 
tion,  theq  :heir  descriptions  would  be  different. 

,  Tables  2,  1,  and  4  also  indicate  another  useful  property.  Notice 
that  the  arias  of  agreement  and  disagreement  vary  by  major  data  item 
category.  ?or  example: 

l.  Documentation  appears  to  be  a  reliable  source  for 

generating  data  items  concerning  the  nominal  teams;  i.e., 


^lt  was  considered  unreasonable  to  duplicate  interviews  with  t lie  same 
SMK.  The  !!MEs  volunteered  their  time  and  would  have  preceived  the 
exercise  ati  being  unnecessary. 

3 When  the  consolidation  effort  was  conducted,  the  preparers  tended  to 
agree  that  the  other  preparer  recorded  the  obtained  information 
correctly,  given  what. the  SME  has  said. 
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preparers  do  not  have  to  make  assumptions  from  the 
documentat ion  when  reading  about  the  nominal  teams.  On  the 
other  hand,  documentation  is  not  a  reliable  source  for 
generating  team  behavior  information.  Preparers  must  make 
too  mar.y  inferences  and  assumptions  to  reliably  identify 
dependencies,  dependency  initiators,  and  recipients,  etc. 

2.  Direct  observation  is  most  suited  to  gathering  reliable 
data  concerning  team  behaviors  and  actual  team  structures, 
but  is  not  particularly  suited  to  generating  information 
about  the  nominal  team  structure  (e.g.,  existence  of 
nominal  team  nested  teams,  etc.). 

3.  SMEs  are  too  variable  to  use  as  a  reliable  source  for 
either  nominal  team  information  or  for  team  behavior 
information. 

One  other  point  needs  to  be  made  concerning  the  consistency 
between  indendent  preparers.  During  the  observation  phase  of  the 
validation  exercise,  a  mission  naive  observer  participated  in  the 
observations.  The  naive  observer  was  familiar  with  both  the  model  and 
the  method,  but  was  not  familiar  with  the  content  and  procedures  of  the 
observed  missions;  i.e.,  he  did  not  read  about  the  missions  or  discuss 
the  missions  with  SMEs.  The  descriptions  prepared  by  the  naive 
observer  looked  different  than  those  prepared  by  the  two  preparers  who 
participated  in  the  review  of  military  documentation  and  the  SME 
interviews.  In  general,  there  was  more  agreement  between  the  two 
independent  preparers  than  between  the  naive  observer  and  either  of  the 
two  independent  preparers.  It  can  therefore  be  concluded  that 
reliability  between  preparers  can  be  increased  if  the  preparers 
understand  something  about  the  mission  to  be  observed  (particularly  the 
general  procedures  of  the  mission). 

It  should  be  mentioned  that  the  degree  of  agreement  between 
independent  preparers  cannot  be  interpreted  as  a  statement  of  accuracy. 
Just  because  two  independent  preparers  generated  similar  descriptions 
when  using  direct  observation,  does  not  necessarily  mean  that  both 
preparer's  descriptions  are  representative  or  accurate.  It  only  means 
they  tended  to  agree  to  record  events  in  the  same  manner.  It  is 
possible  that  the  preparers  were  reliably  recording  inaccurate 
information. 

In  g<  eral,  the  following  statements  can  be  made  concerning  the 
degree  of  consistency  between  preparers: 

1.  Independent  preparers  can  generate  highly  consistent 
descriptions  if  the  input  source  is  "fixed”  (i.e., 
non-variable). 
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2.  Independent  preparers  generate  dissimilar  descriptions  when 
using  documentation  and  SME  interviews  as  the  primary 
source  of  data  or  information. 

3.  The  degree  of  consistency  during  observation  is  enhanced  if 
the  preparers  become  familiar  with  the  missions  before 
conducting  the  observations. 


As  part  of  the  validation  effort,  it  was  necessary  to  determine  if 
the  three  sources  would  generate  similar  descriptions.  To  mitigate 
the  differences  between  preparers,  after  the  descriptions  were  prepared 
from  each  source,  the  preparers  would  consolidate  their  descriptions  to 
produce  a  set  of  descriptions  representative  of  the  source.  It  was 
these  consolidated  descriptions  which  were  compared  to  assess  the 
differences  between  the  three  sources.  Again,  no  statistical 
procedures  were  performed  to  determine1 the  degree  Of  similarity  or 
difference  between  the  consolidated  sets  of  descriptions.  The  sets  of 
descriptions  generated  from  each  source  were  logically  analyzed  to 
determine  general  areas  of  consistency  or  inconsistency.  While  making 
this  logical  comparison,  it  was  quickly  discovered  that  blanket 
statements  could  not  be  made.  For  some  missions,  there  was  remarkable 
similarities  in  the  descriptions,  fcr  other  missions  there  was 
considerable  differences  between  the  generated  descriptions.  For 
example,  the  descriptions  generated  for  Installing  a  Tactical  Minefield 
appeared  remarkably  similar.  There  was  agreement  between  the  sources 
on: 


1.  Existence  of  nested  teams 

2.  Function  of  nested  teams. 

3.  Function  of  individual  team  member  within  nested  teams. 

4.  Dependencies  between  nested  teams. 

5.  Existence  of  dependencies.  i 

6.  Dependency  types.  • 

7.  Dependency  elements. 

8.  Equipment  used  by  nested  teams  (and  some  agreement  on 
assignment  of  equipment  to  individual  team  members). 

9 .  Mission  goal . 

10.  General  mission  procedures. 

11.  Situations  map. 

12.  Sequence  of  mission  activities. 


This  high  degree  of  agreement  between  It  lie  three  sources  can  be 
attributed  to  the  following  factors: 

1.  The  documentation  available  for  Installing  a  Tactical 
Minefield  was  clear  and  relatively  complete. 

.  2.  SMEs  tended  to  use  the  same  documentation  during  the 

interview  as  used  by  the  preparers  during  the  documentation 
phase. 

3.  The  observed  teams  tended  to  follow  the  documentation  when, 
performing  the  mission.  In  fact,  the  observers  reported 
seeing  the  team  leaders  using  the  same  documentation 
material . 

On  the  other  hand,  there  was  very  little  consistency  between  the  three 
sources  for  the  other  missions. 

These  results  seem  to  indicate  that  descriptions  can  be  generated 
from  all  three  sources  with  some  degree  of  consistency  (providing  that 
the  documentation  is  clear  and  complete,  the  mission  procedures  are 
relatively  prescriptive  [as  for  the  minefield  and  bridge  reconnais¬ 
sance],  SMEs  are  experienced  team  members  and  know  what  the  documenta¬ 
tion  prescribes,  and  actual  teams  perform  the  mission  as  it  is 
prescribed  in  the  documentation).  This  is  not  to  say  that  the  descrip¬ 
tion  would  be  accurate  and  identical.  There  is  some  variability  among 
SMEs,  and  I’-.here  is  also  variability  concerning  how  actual  teams  perform 
the  missions  of  interest.  In  fact,  there  were  some  subtle  differences 
between  the  descriptions  generated  from  the  three  sources,  even  though 
the  descriptions  in  general  appeared  similar.  Let's  briefly  discuss 
these  differences: 

i 

1.  The  descriptions  generated  from  observations  are  much  more 
complete  than  those  generated  either  from  SME  interviews  or 
documentation.  SME  generated  descriptions  are,  in  general, 
more  complete  than  those  generated  from  documentation. 

2.  Descriptions  generated  from  observation  tend  to  contain 
more  dependencies.  In  addition,  they  contain  more 
information  to  clarify  and  modify  each  dependency  (i.e., 
observation  generates  more  information  about  each 
dependency  permitting  the  observer  to  classify  the 
dependency  type,  expand  upon  the  dependency  element, 
identify  the  dependency  purposes,  etc.).  It  is  much  easier 
to  ascertain  this  information  from  observation  than  SME 
interviews  or  documentation. 

Dependency  patterns  are  a  particular  problem.  Many 
patterns  can  be  hypothesized  from  the  docuawntation.  In 
addition,  SMEs  tend  to  give  a  specific  pattern,  which  may 
or  may  not  be  observed.  The  only  patterns  that  one  can  put 
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any  faith  in  are  those  patterns  actually  observed  (at  least 
the  preparer  is  certain  that  the  observed  pattern  does 
occur  in  the  field).  Issuance  of  an  operations  order  is  a 
case  in. point.  SME  interviews  indicated  that  most 
operations  orders  (or  frag  orders)  are  issued  by  the  team 
leader  to  the  team  in  a  group  setting.  During  observation 
that  particular  pattern  was  indeed  observed.  However,  so 
were  other  patterns  for  the  same  team  activity.  One  common 
pattern  was  the  issuance  of  the  order  in  a  group  setting, 
followed  by  individual  communicative  dependencies  with  each 
team  member  (to  clarify  each  team  member's  responsibility 
in  the  mission).  It  is  highly  unlikely  the  observed 
pattern  would  have  emerged  either  from  the  documentation  or 
SME  interviews. 

Observation  identifies  more  dependencies  than  the  other  two 
methods,  but  these  dependencies  may  or  may  not  be 
important.  For  example,  during  observation,  more  communi¬ 
cative  dependencies  between  team  members  were  identified 
than  by  the  other  two  sources.  Typically,  these 
"additional"  communicative  dependencies  were  associated 
with  the  following: 

a.  A  supplement  to  another  dependency  (e.g.,  a  hand 
signal  supplemented  with  oral  communication). 
Typically,  SME  interviews  or  documentation  would 
indicate  the  hand  signal,  but  not  the  observed  oral 
communication. 

b.  Contingency  events.  During,  observation,  it  was 

obvious  that  "things"  would  not  always  go  smoothly. 
As  a  result,  "additional”  dependencies  would  occur 
to  correct  the  actions.  Often  these  "additional" 
dependencies  were  not  only  communicative  dependen¬ 
cies,  but  also  procedural  dependencies,  which  could 
not  possibly  be  inferred  from  military  documentation 
or  SME  interviews.  _ 


Directions  and  orders.  SMEs  and  documentation  tend 
to  assume  the  individual  team  members  "know”  their 
assignments.  This  is  not  the  case  during  observa¬ 
tion.  Frequently  team  leaders  issue  communicative 
orders  and  directions  to  either  correct  individual 
actions  or  to  point  out  ways  an  individual  action 
can  be  performed  easier.  These  kinds  of  depend¬ 
encies  are  not  evident  from  documentation  and  SME 
interviews. 


d.  Status  and  verification.  SMEs  tend, to  "forget"  that 
some  dependencies  are  needed  to  verify  that 
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i  n<!  i  v  i  tlii.-i  I  s  have  completed  llieir  missions 

ass igrunents .  Observation  clearly  identifies  these 

kinds  of  dependencies. 

Although  the  observation  method  generated  more  data  and 
dependency  information,  it  is  not  positive  that  these 
"additional"  dependencies  are  important  for  team  training 
purposes  or  team  performance  evaluation  purposes.  Since 
there1 is  some  degree  of  ancertainity,  it  seems  reasonable 
to  suggest  that  the  observation  method  is  perhaps  the  best 
way  to  gather  the  information.  It  is  better  to  have  too  . 
much  information  rather  than  not  enough  information,  given 
that  we  are  in  the  early  stages  of  the  project. 

In  summary,  the  following  statements , can  be  made  about  tHe  degree 
of  consistency  between  team  type  descriptions  and  team  behavior 
descriptions  generated  from  the  three  sources: 

1.  Some  degree  of  consistency  between  the  three  sources  can  be 
achieved  if  the  documentation  is  clear  and  complete,  if 
SMEs  are  aware  of  the  documentation  content,  and  if  actual 
teams  use  (or  at  least  follow)  the  documentation  when 
performing  missions.  This  is  only  likely  to  happen  for 
very  descriptive  missions.  Missions  for  which  the 
documentation  is  ambiguous  (or  allows  for  local  options) 
are  likely  to  he  described  differently  from  all  three 
sources. 

2.  Direct  observation  appears  to  generate  descriptions  which 
are  more  complete  (contain  more  information).  However,  the 
utility  of  this  additional  information  is  not  known.  The 
additional  information  may  either  complicate  or  make  easier 
the  development  and  application  of  the  training  require¬ 
ments  identification  procedure  and  the  performance  measure¬ 
ment  identification  procedure. 

Problems  Encountered 

The  three  specified  sources  have  their  own  unique  set  of  problems. 
The  problems  experienced  were  not  related  to  completing  the  required 
forms  of  the  preliminary  method.  They  wore  related  to  the  ease  of 
using  the  source.  In  the  paragraphs  below,  the  problems  encountered  in 
using  each  source  is  br  ie  1  ly  ■  sunimar  i  zed . 

Wlnni  using  documentation  as  the  primary  source,  the  following 
problems  were  experienced: 

l.  There  was  considerable  variability  in  clearness  and 

completeness  among  the  available  documentation.  As  already 
noted  for  some  missions  the  documentation,  was  clear  and 
complete,  for  other  missions  the  documentation  was  almost 
non-existent. 
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2.  !n  peteral  ,  the  doc ument.it ion  was  not  written  with  concern 
for  team  behaviors.  As  a  result,  the  preparer  is  forced  to 
make  inferences  and  assumptions,  particularly  about  the 
existence  of  dependencies,  dependency  patterns,  and 
dependency  types.  Thus,  the  accuracy  of  descriptions 
j*ene rated  from  documentation  alone  should  be  considered 
suspect . 

1.  The  documentation  typically  provided  little  information 
about  team  activity  sequences.  Typically,  it  discussed 
individual's  activities  causing  the  preparers  to  make 
inference  to  and  about  team  behavior. 

U.  There  were  some  problems  in  actually  locating  the  most 

appropriate  documentation.  The  preparers  found  themselves 
reading  from  various  documents  trying  to  select  the  most, 
appropriate  source  to  use.  In  fact,  a  good  deal  of  time 
required  to  prepare  the  description  was  devoted  to 
selecting  the  most  appropriate  documentation. 

5.  For  each  mission,  many  different  documents  can  be  used  as 
sources*  Frequently,  the  different  documents  contained 
contradictory  information  making  it  difficult  for  the 
preparers  to  make  judgments  and  selections. 

The  SMR  interview  process  highlighted  several  potential  problems. 
However,  some  of  these  problems  were  directly  related  to  the  way  the 
interviews  were  conducted.  If  was  initially  planned  that  each  inter¬ 
viewer  would  conduct  the  interviews  on  a  one-to-one  basis;  i.e.,  one 
interviewer  per  SMK.  One  interviewer,  because  of  the  circumstances, 
had  to  conduct  a  group  interview  (the  size  of  the  group  varied  over  the 
two-day  period  from  two  to  five  SMEs).  It  was  determined  that  the 
group  interview  technique  was  not  a  reasonable  way  to  collect  team 
behavior  information.  The  following  reasons  are  offered: 

1.  The  SMEs  in  the  group  often  had  different  views  about  how 
spec i fie.  missions  should  be  performed.  As  a  result,  much 
dialogue  occurred  between  the  SMEs,  and  the  interviewer  was 
forced  to  select  points  of  view  in  order  to  generate  the 
necessary  descriptions. 

2.  Because  of  the  variability  among  SMEs  in  the  group,  the 
resulting  descriptions  were  not  always  internally 

cons i st  cut . 

3.  It  was  suspected  that  the  group  interview  process  requires 
more  time  to  conduct  per  mission  than  the  one-on-one 
interview; 

In  general,  the  following  problems  were  encountered  during  both 
the  one-on-one  interviews  and  the  group  interviews: 
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1.  Th»>rc  w.is  considerable  var i nl>i  I  i ty  among  the  SMEs  who 
participated.  The  quality  of  the  resulting  descriptions  to 
a  large  extent  depended  upon  the  quality  of  the  SMEs. 

2.  The  interviewers  found  it  difficult  to  explain  exactly  what 
they  were  after.  SMEs  have  different  views  on  what 
constitutes  team  behaviors.  In  fact,  some  SMEs  found  it 
difficult  to  think  about  team  behaviors  at  all.  They  found 
it  more  comfort  able  to  talk  about  individual  activities 
than  team  activities. 

3.  The  quality  of  the  interviewer  also  influences  the 
completeness  of  the  resulting  descriptions.  Interviewers 
must  use  a  probing  technique,  continually  asking  questions 
to  clarify  the  information  that  has  been  volunteered  by  the 
SMEs.  Thus,  the  interviewer  must  "know"  the  model  to 
generate  the  right  questions  at  the  right  time.  Often  the 
interviewers  felt  as  though  they  had  to  "pull"  the  informa¬ 
tion  from  the  SME,  rather  than  have  the  information  flow 
from  the  SME. 

The  interviewers  felt  that  a  structured  interview  schedule 
would  be  difficult  to  develop  for  the  end  user  of  the 
desciption  method,  because  of  the  type  of  probing  that  was 
required . 

4.  SMEs,  although  willing  to  help,  have  other  responsibilities 
and  tin*  time  taken  for  the  interview  is  often  perceived  as 
time  which  could  have  been  devoted  to  completing  those 
responsibilities.  The  extra  duty  attitude  is  indeed  real 
and  may  influence  the  type  of  information  obtained  from 
SMEs. 


5.  Although  the  existence  of  dependencies  was  not  difficult  to 
identify  frotn  SME  interviews,  it  was  often  difficult  to 
"pull"  enough  information  about  the  dependency  from  the  SME 
to  classify  it  by  type,  or  to  determine  its  purpose  or  . 
pattern: 

The  observation  method  revealed  a  set  of  interesting  problems. 
These  problems  were  similar  to  those  experienced  with  the  primitive 
Description  Method  used  during  the  development  of  the  model. 

Basically,  the  problems  webe: 


!.  Observations  can  be  difficult  to  arrange.  The  observed 
FOKS(,’()M  units  must  be  willing  to  participate. 

2.,  The  observers  typically  had  no  control  over  the  "quality" 
of  the  team  observed.  As  such,  one  is  never  certain  if  the 
observed  actual  team  is  representative  of  other  teams  of 
the  same  type.  Thus,  one  never  "knows"  if  the  resulting 
descriptions  are  representative. 


't .  Noli-  taking  during  observation  was  a  real  problem.  The 
observers  found  it  convenient  to  use  audiotape  recorders 
because  of  their  transportability. 

4.  It  was  difficult  during  the  observation  to  set  the  bounds 
of  the. mission  (its  beginning  and  its  end).  Setting  bounds 
from  document  at  ion  and  SME  interviews  appeared  to  be  less 
difficult  (at  least  less  confusing).  During  observation, 
it  was  possible  to  observe  several  missions  being  merged 
together. 

r).  Observing  large  teams  was  extremely  difficult,  particularly 
if  the  team  was  not  organized  into  static  nested  teams. 

h .  The  ability  to  identify  a  dependency,  depended  to  a  large 
extent  on  the  quality  of  the  observer  and  his  or  her 
familiarity  with  the  concepts  in  the  model.  The  preparers, 
however,  felt  that  it  was  easier  to  Ldent i fy  dependenc ies 
(and  to  determine  dependency  types)  from  observation  than 
from  the  other  two  sources.  - 

7.  Some; problems  were  experienced  in  getting  to  and  from  the 
location  of  the  observation.  Often  the  observers  had  to  be 
transported  to  the  mission  site  in  different  vehicles  than 
the  actual  team.  This  meant  that  parts  of  missions  could 
not  he  observed. 

8.  Frequently,  the  observer  had  to  remain  tactical  (in  order 
not  to  betray  the  actual  team  being  observed).  This 
condition  inhibits  the  ability, of  the  observers  to  clearly 
observe  certain  dependent: ies. 

The  discussion  above  indicates  that  there  are  problems  associated 
with  each  of  the  three  sources.  However,  the  problems  do  not  appear  to 
be  insurmountable  .for  any  given  source. 


-The  Final  Desc riptide  Method 

Following  the  validation  effort,  the  project  was  faced  with  the 
task  of  constructing  a  usable  description  method;  i.e.,  to  design  the 
final  versions  of  the  recording  forms  and  to  suggest  the  ways  that  the 
data  items  on  the  forms  could  he  gathered. 

Minor  changes  wen*  made  in  the  recording  forms.  Two  forms  were 
deleted  (the  Deviation  Report  and  the  Actual  Team  Structure 
Organizational  Chart),  while  one  form  was  added  (a  form  to  record  the 
actual  nested  teams  and  their  functions).  The  Deviation  Report  was 
deleted  because  it  was  not  a  recording  device.,  it  was  an  analysis 


device ,  and  as  such,  belongs  in  the  team  training  requirements  method 
and/or  the  learn  per  1  ormance  measurement  method.  Tlie  Actual  Team 
Organ!  zt.  ional  Chari,  was  deleted  because  it  was  cumbersome  to  record  the 
actual  tcan  structure  when  the  actuaL  team  was  comprised  of  many  nested 
teams.  A  form  was  added  to  replace  the  Actual  Team  Structure 
Organizational  Chart  which  requires  tlie  preparer  to  enter  the  name  and 
function  of  each  nested  team,  but  not  to  show  the  relationship  between 
the  nested  teams. 

I 

The  mission  activities  recording  form  was  altered  to  make  it 
easier  to  use.  Conceptually,  the  al Lured  form  was  the  same  as  the 
previous  form,  except  it  no  longer  required  the  user  to  describe  in  the 
space  provided  the  activities  of  the  individuals  who  participated  in 
the  dependency.  The  activities  of  the  individuals  are  described  in  tlie 
comments  column  of  the  altered  form.  • 

A  more  difficult  problem  was  to  determine  how  the  data  to  be 
entered  In  the  recording  forms  were  to  be  generated.  This  determina¬ 
tion  was  made  by  examining  the  validation  results.  A  matrix  was  made 
between  the  required  data  items  and  the  three  sources.  In  the  cells  of 
the  matrix,  comments  were  entered  concerning  how  well  the  source  could 
generate  the  required  information.  Tlie  comments  were  based  upon  the 
experiences  gained  during  the  validation  effort.  The  matrix  appears  in 
Table  5. 

In  addition,  another  matrix  was  constructed.  The  rows  of  the 
matrix  represented  Llie  three  possible  sources,  while  the  columns  of  the 
matrix  represented  the  various  dependency  types.  In  the  cells  of  the 
matrix  were  comments  concerning  how  easy  or  difficult  It  would  be  to 
identtty  the  dependency  types  from  the  various  sources.  This  matrix 
was  constructed  because  t  lie  project  staff  fel  t  that  there  were  some 
differences  among  the  sources  with  regard  to  lx>w  easy  or  different  it 
would  he  io  identity  certain  dependency  types .  Tlie  logic  here  was  that 
tlie  dependencies  were  often  identified  by  first  noting  the  dependency 
type.  Tills  matrix  is  presented  In  Table  6. 

The  two  matrices  were  then  logically,  analyzed  and  it  was 
determined  that: 

1.  Mission  listing  Information  could  be  reliably  obtained  from 
documentation. 

2.  Nominal  team  Information  (structure,  organizational  chart, 
posit  ion  title,  size,  equipment,  etc.)  could  be  reliably 
and  easily  obtained  from  documentation. 

3.  Actual  team  information  could  only  (by  definition)  be 
obtained  from  observation. 

4.  Specific  mission  team  activities  Information  could  be 
obtained  more  reliably  Tram  observation  than  from  any  other 


TABLE  5  (Continued) 
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source.  In  i l  i on ,  tin*  mission  deser  ipt  ions  generated 

from  observation  appeared  to  be  more  complete,  detailed, 
and  comprehensive. 

*).  SMK  interviews  were  only  useful  to  confirm  information 
obtained  from  the  other  two  sources. 

Given  these  determinations,  instructions  were  written  for  completing 
the  forms  (t.e.,  for  generating  the  data  to  be  entered  in  the  forms). 

To  make  the  final  version  of  the  Description  Method  complete,  a 
procedure  for  selecting  the  team  type  to  be  described  and  a  procedure 
for  sampling  missions  were  developed.  These  two  procedures  were 
not  tested  (i.e.,  not  validated),  but  were  offered  only  to  make  the 
system  as  complete  as  possible. 


